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 they need it. They require information to decide 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 includes set of attributes that require decisions to be made by the Authority. The depth of the needed information is negotiated with an understanding of where it might be sourced.
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. But the frames show the attributes needed, a key factor in estimating. When the connections in the model are included as requirements they imply 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. If complex they are split in the model itself. The network gives a full story of the complexity. So an iteration can be sized with knowledge of the interactions needed. Indeed, a set of assertions has connections in and out. The structure of the inputs inform the necessary tests.
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.