1

I am reading a technical standard IEEE 730-2014 which defines the following two activities:

5.4.3 Evaluate product for conformance to established requirements Determine the degree to which the software products and related documentation conform to established requirements.

and

5.4.4 Evaluate product for acceptability Prior to delivery, determine the degree of confidence the supplier has that the established requirements are satisfied and that the software products and related documentation will be acceptable to the acquirer. Collect measurement data sufficient to support these satisfaction and acceptability decisions. A contract may provide that the acquirer, prior to delivery, determine whether software products are acceptable.

Why either alone is not enough? (it is a topic for discussion in a book that describe this standard). I mean - when I meet all contractual requirements (even when the customer wrote them wrong), I did my part and met the contractual requirements. What is then meant by this acceptability evaluation and how does it work in practice?

Improve this question

2 Answers 2

Reset to default
1

Working software is the primary measure of progress

Customer collaboration over contract negotiation

These two phrases from the Agile Manifesto say that success is only achieved when the software solves the customers problems. And as I imagine you have experienced that when picking a fast-food meal, often we don't know what we want or how to solve things - we uncover the solution with trial-and-error. Therefore, we must work together with the customer to test if the planned (contractual) solution actually solves the problem.

How to mitigate the risks of big No's to several months worth of work?

"Customer satisfaction through early and continuous software delivery"

Show and ask often, in small patches. It allows the team to learn about the customer and the customer to learn about the team, and both can converge to a satisfable solution.

A contract is useful for at least two things:

  • Remember that something must be on the software, such as conformity with a regulation;
  • A lawsuit. But this means that this customer will never work with you anymore and you just want to get your deserved money. Don't bring this to the table every week.
Improve this answer
3
  • 2
    In large corporations, delivering for banks or state institution, agile simply does not work -you have a fixed scope, fixed time and fixed price. What you say certainly is true in product development but this is a typical service scenario with a contract stating exactly the requirements.
    – John V
    Commented Mar 14, 2019 at 7:41
  • The first statement is rather bold and would require discussion out of the scope of Stack Exchange. Now, regard the three fixed characteristics you've mentioned, since software development is inherently an intellectual (unpredictable) work, rather a factory-like one, such fixed expectation are doom to fail somehow. In this context, I would still say that continuous feedback loops are recommended in order to mitigate the problems with such conditions.
    – João Farias
    Commented Mar 14, 2019 at 8:09
  • 1
    I would not say so. Even some of the agile "fathers" admit that in fixed price, fixed scope and fixed time contract, there is nothing to be agile about. I agree with you, dont get me wrong, but in these contracts there is no feedback loop. The customer just expects to get his system by a certain date. In 10 years, I have never seen an agile delivery of critical / government software (not speaking about internal Scrum practices etc.) I mean, the reason why we cannot be "agile" is that the reqs are signed off, are a part of the contract, and so is the estimated effort and price.
    – John V
    Commented Mar 14, 2019 at 8:20
0

To me, the first description is acceptance and conformity around what the 'business' side of your team is asking. If a program manager were to say, for example, "Please make sure that you provide a means for our end-users to log in to our website." If you added fields for a username/password and a button to login...well, you have satisfied that requirement, and your end-users are none-the-wiser.

The second, is end-user acceptance, or simply UAT (user acceptance testing). That could mean that you have the aforementioned program manager test the product/change you implemented, it could be a focus group or, pretty much anything customer-facing.

Improve this answer
4
  • 1
    Well but the standard concerns projects with contracts in place. If the contract says "Provide a means to login" and you do that, it is fulfilled, isnt it? I mean, clearly you would test that.
    – John V
    Commented Mar 13, 2019 at 17:45
  • It is fulfilled, yes. My point in the answer is that you are proving the fulfillment internally and then to your customers. Basically, you are validating things twice.
    – Brian
    Commented Mar 13, 2019 at 17:47
  • 1
    But then I do not get why should I worry if this is going to be accepted if all contractual requirements are met? The standard, and the book, imply it is necessary .
    – John V
    Commented Mar 13, 2019 at 17:49
  • I never completely understood the distinction between the two...but, I do know that we put both in to practice here at my office.
    – Brian
    Commented Mar 13, 2019 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.