Showing posts with label Requirements analysis. Show all posts
Showing posts with label Requirements analysis. Show all posts

Friday, February 21, 2014

What is the impact of the ESB on the work of a requirement analyst?


What is the impact of the ESB on the work of a requirement analyst?

  • Work gets easier
  • Helping the requirement analysis
  • Moves the focus to the business events
  • Volère model



Why?

Let's look at the requirement analysis starting point:

Everything begins with the system idea document.
Next step on the list to do: stackholder matrix.
Leading to the business context diagram:
  Mainly covers the actors, parties, processes
  of the business process to support or that needs to be automated
  It should discover all business events coming to the work

Next starting point for requirements trawling:
Starting from the business events
Every business event is answered by a business use case of the work.
Requirement analyst should analyse business use case with use case templates.
Then talk to the solution designers and architects


What is easier?

Business events are coming to the bus!
BA should start work here



Friday, February 14, 2014

Requirements analysis: Business context diagram

Benefit of a business context diagram?

Defines the scope of the work we have to study.
It shows the work as a single, as-yet-uninvestigated process.
It is surrounded by adjacent systems and actors.
Arrows show the data flows between the work and the adjacent systems → carried as business events.

The business context diagram shows where the responsibilities of the adjacent systems start and end.

The data flow makes it clear what work has to be done by the adjacent systems and what has to be done by the work.
Preplanned business use cases that are activated as soon as an actor initiates an business event.


Why does business events and business use cases help?

  • A way to partition the work in a non - subjective way by identifying responses to outside stimuli.
  • Benefit of a clear view of the needed functionality.
  • Internal partitions are mainly the result of technologies, design and history.
  • Business events point out what belongs together.
  • Perfect vehicle for further requirement analysis work!