Chapter 12
Functional Requirements
A functional requirement is something that the product must do, an action
it must take. The fit criterion specifies how you will know that the product
has successfully carried out that action. For functional requirements, there
are no scales of measurement: The action is either completed or not completed.
Completion depends on satisfying an authority that the product has
correctly performed the action. The authority in this case is either the source
of the data or the adjacent system that initiated the action.
Use Cases
A use case, whether it is a product use case (PUC) or a business use case
(BUC), is a collection of requirements, both functional and non-functional,
working toward a desired outcome. While each requirement has its
own fit criterion to measure its performance, the fit criterion for the use case
as a whole is the benchmark for the collection of requirements when they
act together.
(Mastering Requirement Process, pg. 299)
Criteria for Non-Functional Requirements
ReplyDeleteNon- Functional Requirements is a quality that the item should have, for example, ease of use, look and feel, execution, etc. The fit basis is, there-fore, a proportion of that quality. Requirements from the start sight may appear to be miserable and incapable to be measured—there is no deterministic size of coolness.
When people bring the product then we have to target the market and check the opportunities for them. Usually not possible to get the complete, measurable requirement from your first interview. at that point dissect your comprehension, compose your own best translation of the fit model, and you can improve it by discussing it with your stakeholder. You both need to agree t cap your proposed fit basis is an exact estimation of the necessity.
This comment has been removed by the author.
ReplyDeleteFit Criteria for Functional Requirements
ReplyDeleteA functional requirement is something that the product must do an action it must take. The fit criterion specifies how you will know that the product has successfully carried out that action. For functional requirements, there are no scales of measurement: The action is either completed or not completed. Completion depends on satisfying an authority that the product has correctly performed the action. The authority in this case is either the source of the data or the adjacent system that initiated the action.
Functional requirements can be written for different kinds of action. For example, if the action is to record something, then the fit criterion is that the recorded data complies with the data as known to the authority.
For example: -
Description: The app shall record the earnings.
Rationale: The readings are necessary for preparing the revenue report.
Fit Criterion: The recorded earning readings shall be identical to the readings as recorded by the bank account
Use Cases and Fit Criteria
ReplyDeleteA use case, whether it is a product use case (PUC) or a business use case
(BUC), is a collection of requirements—both functional and non-functional—
working toward a desired outcome. While each requirement has its
own fit criterion to measure its performance, the fit criterion for the use case
as a whole is the benchmark for the collection of requirements when they
act together.
To avoid confusion about this use case criterion, we call it the outcome.
That is, this criterion is the intended outcome of the (business or product)
use case if all works as intended. As we are talking about a collection of
requirements, each with a fit criterion, you might prefer to think of the
outcome as a summary (or even summation) of all the individual fit criteria.
Note that some organizations refer to this as the “end state” or the “post
condition” of the PUC.
We suggest that you make use of outcomes very early in your requirements
gathering. During the blastoff (or as soon as you identify the business
events), try to elicit from your stakeholders the intended outcome for each
of their business events. You are asking, “When this business event happens,
what does the business need to achieve?” The answer to this question, with a
little massaging on your part, can be turned into the outcome or fit criterion
for the business use case. As your business use cases evolve into product use
cases, the same or very similar criteria can be applied. You will find, as we
have, that specifying an outcome criterion early in the development process
eliminates a lot of misunderstandings about what each business use case is
intended to accomplish.
As you capture individual requirements, and their fit criteria, keep in
mind that each of them has to contribute in some way to the purpose of
the product. If you have an outcome criterion attached to each use case, it
is easier to ensure that all the requirements you are capturing contribute to
the use case as a whole.