How AM provides a rich foundation for creating your Requirements
Whether your requirements are agile user stories or in a traditional business requirements document (BRD) AM can underpin and generate the Requirements you need.
The nature of Requirements
You can probably find any kind of flavour of requirement method you fancy on the web. Processes, use cases, scenarios, user stories, requirement statement, and so forth. And you can find poor requirements created in all of them. But they tend to have some common ingredients. They are geared to a person, role, persona, user. They have an objective that is a change in state. They have a reason for being needed. Someone should say the need it. They require information to perform and create information that defines the new state.
Here is the INVEST criteria for User Stories and why AM specifically addresses them
Independent: Stories should be as independent as possible.
In AM an assertion is self contained and depends only on the information it receives and sends.
Negotiable: A story is not a contract. A story IS an invitation to a conversation. The story captures the essence of what is desired.
An Assertion has a set of attributes that require decisions to be made by the Authority and that affect the implementation.
Valuable: If a story does not have discernable value it should not be done.
If an Assertion has no downstream connections it is completely valueless.
Estimable: A story has to be able to be estimated or sized so it can be properly prioritized.
Assertions capture a rough estimate of the time to perform and how often. These are not estimates of time to build. When AM Connections are included as requirements(are they user stories or just the missing ingredient) they apply to channels and integrations and are specific enough to be estimated.
Small: Two week iterations which allow for user stories to average 3-4 days of work – TOTAL! This includes all work to get the story to a “done” state.
As assertions are created their complexity becomes apparent as they are elaborated. They are split if other authorities are involved or if other authorities require part of the information generated.
The smaller the user story, the higher the accuracy of the estimate!
Testable: Every story needs to be testable in order to be “done.”
Assertions are automatable. And they support example data. When implemented as a unit they can be tested as a unit. Otherwise the steps of supplying the test information to the software and extracting and inspecting the result becomes the test.
How do Products figure in AM?
The concept of Product figures strongly in Agile and more and more so in other system design.
Definitions stress something physical and of value. Perhaps this is too broad.
It is more likely people mean a software tool or even a software feature. It is particularly important that it is a unit of delivery.
How does a product relate to a service? A service ( with an interface that presents information) is definitely a product.
Does a Product have units of delivery; a start and end?
Without doubt a product fits within a context with a number of stakeholders ( Authorities in AM). And in a software sense (or even in a procedures sense), without it broader efforts would be harder or impossible.
Within the AM sphere, if you have implemented an AM ( with software or manual procedures ) a product can be a replacement collection of implemented assertions that improve use of resources, costs, or accuracy.
In the cloud world Products has come to mean a set of software to support (usually a single user type) for a controlled function. In the world of IT in a large organization. the orchestration between internal and external Products becomes the challenge. Multiple user types and multiple ‘locations’ add a layer of complexity because of the challenges of messaging between them. Sender and Receiver may not interpret the information in the same way. Or there may be risks and cost associated with passing the information to different locations.
Even in generally isolated software products issues of import and export must be accommodated in some fashion.
So for an Assertion Model a View ( a collection of related assertions) becomes the unit of delivery. Its boundary defines the interactions and the one or more Authorities become the customers.