Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Testdata variants - how and where describe them
Previous Previous
 
Next Next
New Post 4/7/2010 12:38 AM
User is offline Joakim
4 posts
No Ranking


Testdata variants - how and where describe them 

Hi all

I'm writing usecases for an integrating system, message broker.

A typical happy flow goes like this
The use case begins when a file including abc-format according to standard xyz, has been received by the system.

1. The system determines and validates sender/receiver. Detailed info : appendix 1
 [AF 1 – Security validation fails]

2. The system secures the file.  Detailed info : appendix 2
 [AF 1 – Security validation fails]

3. The system performs validation-check. Detailed info : appendix 3
 [AF 2 - Validation fails]

4. The system processes the messages within the file and executes corresponding mapping-logic
5. The system sends a positive acknowledgement-message to the external partner.
 [AF 3 - Syntax error]

6. The system transforms the resulting data into proprietary in-house format.
7. The in-house formatted data is sent to the Internal Partner.
8. The use case succeeds.

I have an issue regarding step 4 above. I know that there are ~80 different mapping-logic execution that can take place here. The decision is based on :
* Who sent the file
* Tecnical aspects as fileformat, target directory etc.
* What kind of data the file contains
* Special rules that is used for the actual external partner.

It is important for the testers that all 80 variants is possible to test. I.e all testdata-variants must be described somehow.

Q: Where would You put this documentation and how would You note it? Can I consider these 80 variants as business rules? Or shall it be placed as UseCase realizations? Or, shall it be noted in testdocumentation only?


/Best Regards
Joakim Carlsson

 
New Post 4/7/2010 6:19 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Testdata variants - how and where describe them 
Modified By Kimbo  on 4/7/2010 8:20:02 AM)

Hi Joakim,

What you've written doesn't really conform to what a use case is for at least the following reasons:

1. Use cases are initiated by an actor that interacts with your system. Who is your actor? sounds like its the external system sending the file.

2. Use cases should be solution independent. Looks to me like you're in danger of using a use case to design your interface where there are possibly more solution oriented artefacts that might be more appropriate e.g. a sequence diagram.

There is certainly a use case there as you have a conversation going between the initiating actor, the system and what you call the "External partner" and "internal partner". Whether using a use case is the best approach or not is the question. Personally I don't think so. You need to capture the use case as a function that is performed in your system but the detailed design logic and mapping is best defined separately. I'm a BA, so I don't design. Others on the forum can advise on the best way to do it. I suspect that many will disagree with me too.

Kimbo

 

 
New Post 4/8/2010 12:42 AM
User is offline Joakim
4 posts
No Ranking


Re: Testdata variants - how and where describe them 

Hi Kimbo

Thank You for your answer :-)

> 1) Use cases are initiated by an actor that interacts with your system. Who is your actor? sounds like its the external system sending the file.
Yes, thats true. It's not obvious in the text but this use case is triggered by an actor. There are no human actors involved here. Only system-actors outside this systems boundaries.

>2) Use cases should be solution independent. Looks to me like you're in danger of using a use case to design your interface where there are possibly more solution oriented artefacts that might be more appropriate e.g. a sequence diagram.

Yes You're right. I'm perhaps to close to design ("how") more than describing desired behaviour ("what"). However, the detailed steps are mandatory because they descibe a standard way on how distribute finance-information between systems. I'm striving though to be vendor-independent.

I don't want to place detailed datavariants in the use case. That info shall be placed in a design- or test-artifact I believe. I just don't know which suits best.

/Best Regards
Joakim

 

 
New Post 4/13/2010 7:04 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Testdata variants - how and where describe them 

 Hi Joakim,

I was perhaps a bit harsh in my earlier post cause I was trying to make a point about solution independence. You're just missing a first line or two that specifies the trigger from the external system. The rest is just a question of a bit of a re-write but whatever. 

To answer your specific question

Q: Where would You put this documentation and how would You note it? Can I consider these 80 variants as business rules? Or shall it be placed as UseCase realizations? Or, shall it be noted in testdocumentation only?

I think you need a separate interface specification that will include things like:

1. Data mapping between the information coming in and where it will go to in your system. You also need to specify where the values for fields not coming from the external system in the resulting records are sourced from. e.g. they are defaulted or you look up a table in your system, etc.

2. Perhaps a data model of some kind - class diagram or ERD of your system so the reader can see the resulting data structures

3. The set of 80 rules as validation rules for the data load process

4. Rules for what happens when validation fails (one of the 80 validation rules fails) / error processing. Some may just write to an error log and proceed; some may cause the load to fail completely i.e. there may be classes of failure that have different consequences.

5. Your use case should show error processing that changes the conversation with the other systems (actors).

Plus probably some other things that I haven't thought of. Haven't written one of these for a few years.

I see requirements modelling as three levels - requirements (textual statements); process and functional requirements (I use use cases but dfd's work too); UI, reporting, interface specifications. I'm simplifying but what I'm trying to say is that the interface specification is the next detailed step after you have your use cases.

Kimbo

 
New Post 4/20/2010 5:35 AM
User is offline Joakim
4 posts
No Ranking


Re: Testdata variants - how and where describe them 

Thanks Kimbo for your terrific advices! :-)

I'll look inte the Interface Specifications and see if I can easily handle the Business rules/Data variants in that artifact.

/Best Regards
Jocke Carlsson

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Testdata variants - how and where describe them

Community Blog - Latest Posts

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada ...
Hosted by Deirdre Caren in Agora Insights' Blueprints for Success I'm thrilled to have Susan Moore join us for episode 9 in our Blueprints for Success. In this session, Susan shares her rich tapestry of experiences that have shaped her career. Her journey into business analysis (ba) is a compelling narrative of exploration and disco...
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC