Basic concepts of Requirements in AM
How does an Assertion relate to Use Case, Requirement, User Story, Tasks etc?
Business Requirement Documents (BRD) have many formats. This speaks to the lack of consensus on what the BRD does. There are two perspectives of Requirements. The first is a statement of how a system is expected to perform. The second is the project mechanics of assembling this description and implementing it. Often a BRD includes responsibilities for signoff, a division of effort, perhaps testing etc.
How do Requirements relate to the Business Model (often in BPMN)?
The current practice of Requirements gathering usually involves Business Analysts populating part of a BRD in consultation with subject matter experts(SMEs) and perhaps some supporting documentation.
The level of detail at this level is quite varied; often issues are kicked down the road because of lack of time or of reluctance to assign responsibility.
The difference between requirements for business, product, or scientific domains.
Often advice and templates for requirements do not identify the domain of the requirements. Producing requirements to capture scientific or engineering events is quite different. Sometimes templates for this kind of exercise creep into business requirements and confuse the issue. Also requirements for a business system and for a product differ markedly. A product is commonly single function focused with a single user profile. It commonly supports a configuration type of function, assisting the user to orchestrate a number of factors to optimize and then deliver a configured set of values. In business requirements the system more often has a number of user types ( roles, personas, etc). Often too, the system crosses or interfaces with other systems that are out of scope. In addition, some of the roles are ‘located’ (physically and environmentally) separately. The required system must address this. And cannot be considered as monolithic. And expectations of incremental adjustments begin to reduce the value of large system specifications.
The problem with hierarchy
Most BRDs attempt to divide and conquer. So they try to present a classification hierarchy to help with the issues of work assignments for building the requirements and for building the implementation. This subdivision begins to add impediments for the communication and interaction between the parts. Often the interrelationships are ignored so that the piece itself can be specified or built. Integration in some cases is created as a separate project function.
The problem with implementation
Larger transformations cannot be implemented in a single environment with a single implementation method. Sometimes a software product forms part of the solution. Some needs are implemented out-of-the-box. Some require configuration. Some require additional scripting in the product itself. Some cannot be implemented in a single product. Some may require separate development of user interfaces. some may require interfaces with existing systems. Implementation is a business decision, just like deciding on scope or detail in the business description itself. It is not possible to plan grandiose go-live events any more.
The Agile Imperative
In the search for a better way, the new, hazily understood, method always seems to beckon over the current confusion. And methods that find success in one domain are touted and taken up where their efficacy is limited. Can a large system be built in small pieces, implemented bit by bit? Will any system stay monolithic or will the trend to continuous improvement require constant changes. Is the big system project a thing of the past.
The cost of a Requirement
It is difficult to know in advance what the implementation cost of a single requirement is. Is it cost justified? Will it likely be abandoned in implementation because it was too ambitious? Have you ever gone through the priority process for requirements? Must, Should, Nice-to-have, Release 2. You were lucky to have the time to prioritize.
How does implementation planning use the requirements? how are releases configured.