Business analysts are those who can support the enablement of a change. A change may be a new feature on a system, a new system or a change in procedures. One of the main tasks of business analyst is to elicit requirements. By elicitation we mean a dynamic process that is beyond just collecting customer's requests. It's more about negotiating, challenging and elaborating on what customers say they need. Then it’s a task of the business analyst to define those requirements in a usable and concrete way.
However in elicitation and defining requirements great analysts have in mind the value that needed to be delivered and the alignment with the whole context. This can be far more challenging than just discussing about specific features of the product in a workshop with clients.
A business analyst should avoid approaching requirements as piles of isolated objects. Human organizations and the mutual interaction between people and organization that provides a system, indicating the need of thinking the requirement as part that should harmonically be integrated to the whole puzzle.
Business architecture is important. As a business analyst you need to bring context to the environment in which the solution or change must be implemented.
Before a BA starts formatting the requirements after collecting and analyzing them, he need to take into account how those requirements will function collectively with other elements of the organization like processes and business rules. A great BA has to dive into the business architecture and to ensure the requirements are not only aligned with project objectives but also with organizational goals and structure.
Mastering BA meaning you have to go beyond the surface of collecting and elicitating requests for new features. You have to collect evidence about the strategic plan and direction of the company. Make as much questions as possible to identify those things.
BEYOND VALIDATION AND VERIFICATIONIt is important to consider how your project and consequently the solutions that will be developed as part of it , no matter how small, will support the strategic goals of the company. Beyond verification and validation of the requirements you need to perform a check also for the alignment with the context and the level of strategic fit with the high level organizational goals. Although the project scope is supposed to be aligned with the goals of the organization checking either requirements with small impact for their strategic fit can be valuable.
As an analyst the more aware you are of the philosophy and the specific characteristics of the organization you will develop solutions the more focused your work will be and the more on target your requirements elicitation will be.
As an analyst you have to ensure your own understanding of the bigger picture. You have to zoom in and zoom out frequently. You need to analyze either in small initiatives the context under which the ba work will take place. It is possible to get so focused on the solution that your thoughts are stuck only in delivering the solution and forgetting to revisit frequently the alignment with the scope and the context. The BA always needs to ask if the task being performed is not only moving the project toward its goal(s) but also providing value to the organization.
Credit - George Sioutzos
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, migration is not enough. To overcome the modern challenges and step ahead of the tight competition, tech enterprises both large and small need a more sophisticated approach to cloud-based app development. One of the best advantages is that it encapsulates everything from development to deployment; everything from how we design, build and manage software, all under one roof. If your enterprise is still not completely aware of the benefits of the cloud in application development, let us give you a walk-through, so that you understand the advantages and utilize the cloud.
THE NEED FOR CLOUD COMPUTING IN APPLICATION DEVELOPMENT
Every application nowadays consists of data and processing logic stored as code and needs an efficient storage space to be run effectively. Users of cloud-based applications interact through a mobile application downloaded from Playstore or Appstore or can even interact from the browser, and the data processing takes place on the remote server base and is handled with the help of an API. In this case, a user’s device serves only as of the input device and does not host the majority of processes therefore the applications perform efficiently and without any. Besides, a cloud-native software or application makes digital operations more streamlined and implements greater flexibility for businesses of any size.
Enterprises would need to align their applications, so as to utilize the cloud service models that it offers. Some of the typical benefits are listed below:
Cost-effective: Cloud computing eradicates the capital expense of buying and maintaining hardware and software. As mentioned earlier both hardware and software can be accessed over the internet through the service models. It also eliminates the cost of running racks of servers, on-site data centers, electricity for power and cooling, IT experts for managing the infrastructure, and much more. The service providers such as Amazon AWS or Microsoft Azure provide services as pay per usage, the infrastructure is also not purchased thus lowering maintenance.
Enhanced Speed: The cloud computing services are given by service providers on the customer's demand, therefore even fast amounts of computing resources, platforms, or tools can be provisioned in a few minutes. This means with just a few mouse clicks unlimited storage space can be accessed, cloud development platforms can be utilized and backup maintained. This gives companies and enterprises a lot of flexibility to manage operations; thus seamlessly takes the pressure off of the IT team and infrastructure maintenance team.
Better Productivity: There are several demands for on-site datacenters that normally range from continuous racking and stacking device setup as well as software patching, and other time-consuming IT management processes. Cloud computing eliminates the requirement for many of these tasks therefore the IT teams can spend more time on solving important business goals.
Increased Performance: The most significant cloud computing services are operated on a worldwide network of reliable data centers which are frequently upgraded to the most advanced generation of fast and efficient computing. This suggests various advantages over an individual corporate data center, including diminished network latency for applications and bigger economies of scale.
Security: Cloud service providers such as Amazon AWS and Google Azure offer a broad sense of policies, technologies, and controls that strengthen the security posture overall. This helps enterprises with huge resources to protect their data allocations and infrastructure from upcoming threats and malware.
MORE REASONS TO OPT FOR CLOUD-BASED WEB DEVELOPMENT
Further, before developing an appropriate cloud-based application, developers can choose from the three cloud service models various services, and use cases. This makes it much easier for developers as the cloud itself provides the tools, platforms, hosting services, and much more to develop applications. Few of the predefined services that cloud provide developers are listed below:
Readymade Software (RMS): It offers predefined codes or low code development strategies for standard software such as email systems, payroll applications, ERP systems, etc.
Web Hosting (WH): Hosting and maintaining an organizational website.
Data Storage (DS): Cloud provides unlimited storage of any kind for organizational data or backup and recovery, archiving, document management, and much more
Network Server (NS): An efficient and reliable computer server that is used for seamlessly storing and running databases, mail, or business applications.
Computer Network (CN): Cloud also offers a computer network that can be efficiently used for establishing an intranet and/or extranet.
Cloud computing is a continuously evolving technology that is currently being increasingly adopted because of the multiple benefits and use cases. Prominent cloud technology leaders, such as Google, Amazon, and Microsoft have contributed their leadership in developing more advanced innovations in cloud computing. There are several technological groups out there, such as the Cloud Security Alliance or the Open Cloud Consortium, which was formed to explore the opportunities offered by cloud computing. From cloud deployment models to cloud service models, there is always something about the cloud that pushes organizations to adopt cloud and enhance their operations.
When customer expectations are high and timelines are short you need to make sure your project team delivers the most valuable functionality as early as possible.
Prioritization is the only way to deal with competing demands for limited resources.
Stakeholders on a small project often can agree on requirement priorities informally. Large or contentious projects with many stakeholders demand a more structured approach. You need to removes some of the emotion, politics, and guesswork from the process. This article discusses several techniques teams can use for prioritizing requirements and some traps to watch out for.
Two Big Traps
Be sure to watch out for “decibel prioritization,” in which the loudest voice heard gets top priority, and “threat prioritization,” in which stakeholders holding the most political power always get what they demand. These traps can skew the process away from addressing your true business objectives.
In Or Out
The simplest method is for a group of stakeholders to work down a list of requirements and decide for each if it’s in or it’s out. Refer to the project’s business objectives to make this judgment, paring the list down to the bare minimum needed for the first iteration or release. When that iteration is underway, you can go back to the previously “out” requirements and repeat the process for the next cycle. This is a simple approach to managing an agile backlog of user stories, provided the list of pending requirements isn’t too enormous.
Pairwise Comparison And Rank Ordering
People sometimes try to assign a unique priority sequence number to each requirement. Rank ordering a list of requirements involves making pairwise comparisons among all of them so you can judge which member of each pair has higher priority. This becomes unwieldy for more than a few dozen requirements. It could work at the granularity level of features, but not for all the functional requirements for a good-sized system as a whole.
Rank ordering all requirements by priority is overkill, as you won’t be releasing them all individually. You’ll group them together by release or development iteration. Grouping requirements into features, or into small sets of requirements with similar priority or that otherwise must be implemented together, is sufficient.
A common approach groups requirements into three priority categories. No matter how you label them, if you’re using three categories they boil down to high, medium, and low priority. Such prioritization scales usually are subjective and imprecise. To make the scale useful, the stakeholders must agree on what each level in their scale means.
I like to consider the two dimensions of importance and urgency. Every requirement can be considered as being either important to achieving business objectives or not so important, and as being either urgent or not so urgent. This is a relative assessment among a set of requirements, not an absolute binary distinction. These alternatives yield four possible combinations (Figure 1), which you can use to define a priority scale:
* High priority requirements are important because customers need the capability and urgent because they need it in the next release. Alternatively, there might be compelling business reasons to implement a requirement promptly, or contractual or compliance obligations might dictate early release. If a release is shippable without a particular requirement, then it is not high priority per this definition. That’s a hard-and-fast rule.
* Medium priority requirements are important (customers need the capability) but not urgent (they can wait for a later release).
* Low priority requirements are neither important (customers can live without the capability if necessary) nor urgent (customers can wait, perhaps forever).
Watch out for requirements in the fourth quadrant. They appear to be urgent to some stakeholder, perhaps for political reasons, but they really aren’t important to achieving your business objectives. Don’t waste your time implementing these—they don’t add sufficient value to the product. If they aren’t important, either set them to low priority or scrub them entirely.
Figure 1. Requirements prioritization based on importance and urgency.
On a large project you might want to perform prioritization iteratively. Have the team rate requirements as high, medium, or low priority. If the number of high-priority requirements is excessive and you can’t fit them all into the next release, perform a second-level partitioning of the high-priority ones into three groups. You could call them high, higher, and highest if you like, so people don’t lose sight of the fact that they were originally designated as high.
Those requirements rated “highest” become your new group of top-priority requirements. Then, group the “high” and “higher” requirements in with your original medium-priority group
Figure 2. Multi-pass prioritization keeps the focus on a manageable set of top-priority requirements.
Watch for requirement dependencies when prioritizing with the three-level scale. You’ll run into problems if a high-priority requirement depends on another that’s planned for later implementation.
The four capitalized letters in the MoSCoW prioritization scheme stand for four possible priority classifications:
Must: The requirement must be satisfied for the solution to be considered a success.
Should: The requirement is important and should be included in the solution if possible, but it’s not mandatory to success.
Could: It’s a desirable capability, but one that could be deferred or eliminated. Implement it only if time and resources permit.
Won’t: This indicates a requirement that will not be implemented at this time but could be included in a future release.
The MoSCoW scheme changes the three-level scale of high, medium, and low into a four-level scale. It doesn’t offer any rationale for making the decision about how to rate the priority of a given requirement compared to others. MoSCoW is ambiguous as to timing, particularly when it comes to the “Won’t” rating: does it mean “not in the next release” or “not ever?” The three-level scale that considers importance and urgency and focuses specifically on the forthcoming release or iteration.
Agile projects often use the MoSCoW method, but I’m not a big fan of it. Here’s how one consultant described how a client company actually practiced the MoSCoW methods:
All the action centers around getting an “M” for almost every feature or requirement that is captured. If something is not an “M” it will almost certainly not get built. Although the original intent may have been to prioritize, users have long since figured out to never submit something that does not have an “M” associated with it.
Do they understand the nuanced differences between S, C, and W? I have no idea. But they have figured out the implications of these rankings. They treat them all the same and understand their meaning to be “not happening any time soon.”
One way to make prioritization more tangible is to cast it in terms of an actual resource: money. In this case, it’s just play money, but it’s money nonetheless.
Give the prioritization team 100 imaginary dollars to work with. Team members allocate these dollars to “buy” items they’d like to have implemented from the set of candidate requirements. Allocating more dollars weights the higher-priority requirements more heavily. If one requirement is three times as important to a stakeholder as another, she might assign nine dollars to the first requirement and three dollars to the second. But 100 dollars is all the prioritizers get—when they’re out of money, nothing else can be implemented, at least not in the release they’re currently focusing on. You could have different participants in the prioritization process perform their own dollar allocations, and then add up the total number of dollars assigned to each requirement. That will show which ones collectively come out as having the highest priority.
Watch out for participants who game the process to skew the results. If you really, REALLY want a particular requirement, you might give it all 100 of your dollars to try to float it to the top of the list. In reality, you’d never accept a system that possessed just that single requirement.
Nor does this scheme take into account any concern about the relative amount of effort needed to implement each of those requirements. If you could get three requirements each valued at $10 for the same effort as one valued at $15, you’re likely better off with the three. The scheme is based solely on the perceived value of certain requirements to a particular set of stakeholders, which is a limitation of many prioritization techniques.
It’s Not All Going To Fit
Sometimes customers don’t like to prioritize requirements. They’re afraid they won’t ever get the ones that are low priority. Maybe they won’t. But if you can’t deliver everything, make sure you do deliver those capabilities that are most important to achieving your business objectives. Prioritize to focus the team on delivering maximum value as quickly as possible.
Credit BA Times
Are you interested in learning more about becoming a good, or even better Business Analyst?
Then I highly suggest you enrol for our BA Career Coaching.
Contact us at Jadetan Enterprises Ltd via