ASR
The successfully captured ASRs would determine the success factor of the project/product. So, ASRs would be part of requirement management, and it needs to be nurtured and articulated well
The Architecturally Significant Requirements (ASRs) forms the foundation elements of the system design. The successfully captured ASRs would determine the success factor of the project/product. So, ASRs would be part of requirement management, and it needs to be nurtured and articulated well. Any mistakes in this critical step / early stages of project evolution will have significant impact on the overall delivery of the project.
What are ASRs?
Why someone determine the requirements are significant? What made them as significant? The answer is simple – because the designated architect / senior developer feels so. However, its impact is so huge in-terms of Total Cost of Ownership (TCO), timelines/schedules, decisions, future business model/roadmaps, MVPs, build vs buy etc. It can be only determined by seasoned professional like architect – no one else. Let’s take examples of ASRs –
1. The proposed solution should be hosted in cloud environment and must support multi factor authentication (MFA)
2. The proposed system expected to receive 10-12 million IoT telemetric data / per hour from 1000+ engineering devices from the production plants spread across APAC region
3. The user interface elements must be responsive in nature and should be accessible from desktop, laptop, and mobile/any hand-held devices with all popular browsers
Now, if you look at above examples – one must make important decisions at very early stages of the project, choice of cloud vendor, proposed deployment cost / TCO, capacity planning, challenges in data storage / computational cost etc. Any failure in these decisions will have impact on project schedule, cost – some decisions like choice of cloud vendor can’t be changed in the middle of the project execution, it is such a foundational requirement, hence the word “significant”.
Challenges of capturing ASRs
The requirement management is very challenging task and should be carried out by very experienced staff. The requirement gathering will have following key challenges, that team must navigate to come up meaningful conclusions.
No clarity in user needs - The vague / not clear requirements which are very hard to articulate and describe
Always evolving - At times, due to change in business decisions, the foundational requirements might change, thus triggering catastrophic dependent changes
Conflicting Interests – Business community / Project stakeholders are divided into multiple opinions with conflicting interests / priorities, hence consolidating ASRs would become challenge
Who determines ASRs?
Who determines the ASRs? From the set of requirements, finding out architecturally significant one is not easy for novice developers. It requires very deep-rooted experience in executing enterprise solutions those are complex in nature – both business and technical point of view. IMO, the seasoned architects / senior developers would categorize the requirements are important as its impact on the system is very large. So, there are 02 major driving forces:
1. Business wide impact
2. Technical complexity
The requirements that fall on “High-High” quadrant should be the candidates for Sprint-0 activities. The stories shall be broken down and related architecture decisions shall be finalized. One can choose to have “big upfront vs evolutionary” approaches depending on the information availability.
The stories under Low-Low quadrant are low fidelity topics – for example – CRUD operations on list of values. It does not need to be having UI for all admin screens, at time, simple SQL statements with technical support team would do the job – at least for initial go-live.
Characteristics of ASR
The requirements carry intrinsic characteristics, a seasoned architect / domain expert would identify during requirement gathering or analysis phase. The categorization of requirements into specific category would help in architecture decision making. Broadly, the ASRs shall be grouped into below types –
Complexity – They are highly complex in nature from a technical point of view. It requires lot of analysis to come up feasible solutions to address such requirements. For example – Most of the highly scalable e-Commerce solutions will have complex technical requirements.
System wide Impact – Some requirements are common (think as shared service) in nature and widely used across system functions. Hence, to develop solutions around these requirements would demand more effort. Also testing will be more as it touches many system boundaries. It has significant impact on architecture development. For example – creating the event logs in event driven architecture. It is such a important feature in highly distributed / transactional environment.
System essentials – As name suggests, these types of ASRs are determined by the key stakeholders during the workshop, and it must be addressed in architecture. These requirements carry high SLAs and would play pivotal role in system acceptance.
Strategic importance – Few of the requirements may not be complex in nature at least from technical aspects, however, those are of high importance from the business growth point of view. For example – seasonal discount offering on the products / those are region / country specific.
ASR Capturing Workshops
The requirement gathering sessions shall be planned very well in advance by checking the availability all the key stakeholders. Following are success factors to be considered for successful conclusion of requirement gathering workshops. IMO, it might have many more such topics and I tried to list down few of them, that I have come across in my experience.
1. Alignment on project objectives and its intended benefits among with key stakeholders
2. Identification of requirement review mechanism and approval committee
3. Requirement workshop timelines / high level plan finalization
4. Alignment on requirement change management / scope changes and its impact on cost and schedules
5. Usage of requirement tools
6. Iterative approach for the requirement gathering, review, rework and sign-off
7. If possible, record the discussions and share with development team members for any feedback during requirement gathering period
8. Elicit the requirements / breakdown into user stories
9. Create a repository to store all client supplied initial documents – before starting new requirement gathering sessions
10. Establish the frequent feedback mechanism to correct any gaps and move towards sign-off
11. Validate the requirements with acceptance criteria
12. Segregate the requirements by business functions, NFRs and other categories for better management
13. Requirements shall be written in clear language – that would be understood both business users and development team members. Also, provide any additional commentary on the requirements which deemed to be complex in nature OR it would have taken lot of discussions with stakeholder community.
ASR Identification challenges and its impact
Once the requirements are captured and analyzed, we often tend make some mistakes. At times, we give much importance to functional requirements, UI driven use case scenarios etc. and will ignore non-functional requirements (I have my own perspective on naming as Non-Functional word, however it is popularly used, so I will keep it as is) – those have system wide impact. This will lead to lot of challenges during system acceptance. Also, few requirements are written in a hurry without full consent from the key stakeholders leading to scope creep / misunderstanding during implementation phase. It is important that, all business users are read the needs and duly sign-off for the next step. Also, any change in requirement during active development phase might impact the overall schedule, so such changes shall be discussed and prioritized depending on its complexity / OR impact. It is expected that, in large enterprise solutions, the implementation plan might run into couple of years and obviously there will be change in business context. So, change management shall be discussed clearly with stakeholders during / after the gathering sessions. Please note that, ASRs are foundational elements of the system architecture, any gaps either in change management or initial sign-off might lead to cracks in design lead to serious challenges in solution acceptance. The factors such as cost, business priority, tech complexity, system wide impact, availability, scale, performance, usability etc., would determine its identification challenges.