Are terms that are part of the process of Requirements Engineering.
As there is a lot of technical literature available (see links in the end) in this regard, this answer is an "practical example" (fictional and simplified):
Setting
The company will develop software for a securities broker and below follows a passage from the dialogue between the analyst responsible for lifting requirements and the customer (manager).
Interview
. . .
Manager - I also need the system to provide me with a report Realtime of all operations
made by customer. The highest value ones are the most important to me, because if it is necessary to take
some providence I have to act quickly.
Analyst - What information does this report need to have?
Manager - Now...the basic, value of the operation, whether the origin was the table or home Broker, ... and the balance of each client, already discounting
charges, brokerage fees...But if it is a uncovered sale, chiefly day trade, I need this to appear in red
in the system because it may be a problem.
Analyst - Day Trade?
Manager - Yeah! Day trade, bought and sold on the same day.... I need to know right away!
Analyst - And if at any time the system becomes unavailable?
Manager - This system cannot be unavailable!!
. . .
From the above dialogue, it is possible to perceive (example) the following requirements (besides the importance of Requirements Engineering):
The system shall generate a report with the information:
- operation
- action (
XYZ
, in this example)
- day_trade
(data da compra de XYZ na carteira do cliente == data da venda dessas ações)
- discovery
( (número de XYZ na carteira do cliente - número de XYZ vendidas) < 0 )
- origin of the transaction
- client’s debit balance
Sort by: day_trade, discovery, start_operation (decreasing)
There are several subdivisions here, but simply:
Requirements of Usability:
- "appear in red"
- "Discovery sale, mainly day trade"
The background colour of the lines in the report shall be RED for the following condition:
(day_trade = Verdadeiro) OU (descoberta = Verdadeiro)
Efficiency requirements:
Reliability requirements:
Delivery requirements:
- "Realtime"
- "I need to know that right away"
- "This system cannot be unavailable"
The system must have a connection fee system
The system shall have an electrical redundancy system
The system must have physical redundancy
for more information: GROUNDS OF FAULT TOLERANCE
Domain requirements are derived from the domain of the system application that may be new functional requirements per se, may restrict existing functional requirements or establish how specific calculations are to be performed.
The field of application in this example is "a securities broker operating in the financial market".
An example of a domain requirement: please refer to the legislation (in the field of application, ex: CVM) to perform properly
the calculation of fees.
This legislation may even generate new functional requirements (not foreseen by the customer) or restrict requirements already requested.
Links on the subject:
Article Software Engineering - Introduction to Requirements Engineering
Requirements engineering: processes and techniques in the organizational context
Google: pdf requirements engineering
Google: non-functional and domain pdf functional requirements
Really, these concepts of requirements engineering cause a lot of confusion, thanks for the answer, clarified several doubts of mine.
– gato