While preparing a Developer level Document (Use Case) what should be defined in Business Validation?

Question

We are working on a developer-level document or a Use Case document which is shared with the development team. We define Business Validation within a use case, what should be a part of that Business Validation? Please explain?

Like for example, we are writing a use case for creating a user, what should be involved in Busines Validation?

Answer 1

As per Wikipedia, Business Process Validation (BPV) is the act of verifying that a set of end-to-end business processes function as intended.

In other words, this is not checking that the app doesn't crash, rather, it's checking the app does what you designed it to do.

So, in your example of writing a use case for creating a user, the Business Validation would include the ability to retrieve the user - and all the information they included when signing up.

It could also tests to ensure that the user is uniquely identified in the system; that there's no way the system will confuse users with identical names, for example.

For that matter - depending on the spec - it may refuse to create new users with identical "identification".

It could also include checks to ensure their payment method is valid, their password is of correct length & strength and that - if implemented - they have confirmed their email by clicking in the email they received by the system.

In the latter case, it would define what the user can/cannot do until they have confirmed their email - and this too has to be checked that it is implemented as expected.

Answer 2

Ask the customer, user or business team what validation they would expect. Keep the documentation as brief and simple as possible. Encouraging the users to see and try out the software, talk to the development team and give their feedback is much more important than what you write down in any document.

Answer 3

"Like for example, we are writing a use case for creating a user, what should be involved in Busines Validation?"

Best approach is the clearly define which actors are involved, the depender and dependee. then show the actual role of each to the dependum(Current use case).

Use Case are meant to be simple, if we talking creating,

• who has rights to create a user?
• are there different user?(admin/client/customer) with different roles and privileges to the system. Each should be specific to each user case.

Answer 4

Business validations (from my personal experience - what would I consider, decomposing the story into the requirements - functional and non-functional):

1. Data inputted/gathered/ pushed to the System meets the business rules, which usually are: min/max amounts, length, data format/ extension, is data expired or not, SLAs; structural/compatibility (e.g. 'mini-USB cable cannot be bundled with iPhone 12', as will not bring business value) - this one is dependent on the business domain you're researching and creating the use cases in.
2. Non-functional requirements: timeouts, types and format of errors, etc. Note: scenarios of error handling itself and service maintenance, I think, should be also use cases (i.e. need to decompose them in the same way as described in these bullets), security (role, level of access).
3. Assumptions: what the System/ exact component does not or does in a specific way because of , what it's dependent on, technical limitations, etc.