Entries for 'adrian'

Having discussed fields intended to name record instances, we move on to fields intended to satisfy the need to say something quantitative about a record. A quantity field requires particular attention be paid to its unit of measure (UoM) and precision. 

In this article we focus on record name fields. These fields are intended to contain a user-recognizable value by which a person or thing is known, addressed, or referred to. Unlike a record business identifier field, a name field’s value may change over time. Also, there are ‘real world’ names for things (e.g. people, cities) for which valid duplicate values can exist. 

As Business Analysts, when we’re at the sharp end of solution delivery that doesn’t match a customers needs, at that time it just can’t be rectified and we can’t help thinking that we might have been able to prevent this at the early stages. In this article we’ll explore 3 ways to get out the trap of being solution oriented up front to shift more into the problem and needs to get better requirements. 

Having explored information system record concepts, the objective of this article is to examine one particular type of field — the record business identifier. Its purpose is to uniquely identify an instance of a record.  Users of an information system are expected to have knowledge of, or access to, this value. The value is used to start down, or stay on, the ‘happy path’ of any business process that deals with the specific record instance it identifies.

Data has emerged as the sole driver of the digital transformation of the present world. It has turned into the most significant resource, and without it, one couldn't really expect to succeed in today's crowded market. Organizations should proficiently utilize their data since it very well may be a factor that can differentiate you in corporate development.  This requires the compelling combination of artificial intelligence with data analytics for enhancing business processes.  The automated direction along with data-driven decision-making is rapidly turning into the standard in this digital world. Since the assortment of data and its analysis is more reachable than any time in recent memory, organizations of all shapes and sizes are leveraging this innovation, hence, noticing noteworthy outcomes. Yet, luring those significant experiences out of your data can be challenging when you reach "big data" extents.

This article discusses record types supporting the concepts product, customer, sale, and location. The names given to these records varies depending on the line(s) of business an organization is in and, in particular, the organization’s sales processes.

There are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.

As a data analyst, you feel most comfortable when you’re alone with all the numbers and data. You’re able to analyze them with confidence and reach the results you were asked to find. But, this is not the end of the road for you. You still need to write a data analysis report explaining your findings to the laymen - your clients or coworkers.  That means you need to think about your target audience, that is the people who’ll be reading your report.  They don’t have nearly as much knowledge about data analysis as you do. So, your report needs to be straightforward and informative. The article below will help you learn how to do it. Let’s take a look at some practical tips you can apply to your data analysis report writing and the benefits of doing so.

This series is about understanding data fundamentals applicable to information systems. In this article and the next, record types specific to an organization’s line(s) of business are discussed. These records support maintaining data for an organization’s Products, Customers, Sales, and sale-related Locations. They will be viewed within the context of five generic line of business functions that represent the business processes involving any product as it goes through its lifecycle.

Put an end to all your frustration and lost hope; well, the reason and the culprit could be your resume and not your skills or education.
Your resume is your front face or the outfit of your professional profile. Hence it fetches or attracts eyeballs based on its appearance and how it is presented. Here are the 5 top tips to polish your resume to bag the best business analyst jobs...

A software feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. Many business analysts use features as a way to describe the scope of a project. However, a simple list doesn’t readily show the size and complexity of various features. Nor does quickly skimming a feature list easily reveal the full scope of a project. A feature tree is a visual analysis model that organizes a set of features in a format that makes them easy to understand.

We begin our exploration of information system data fundamentals by looking at types of records applicable to any organization. Records such as     GL ACCOUNT, STAFF MEMBER, and ASSET are well-understood within any organization large enough to warrant information systems supporting Accounting, Human Resources, or Asset Management functions. These functions and record types are well supported today by commercial off-the-shelf (COTS) packages. So well supported, it’s difficult to imagine any organization justifying a decision to develop an in-house solution rather than buy a commercially available one.

This is the first of a series of articles intended to help business analysts deal with the information aspect of information systems during requirements elicitation. Requirements are commonly categorized as either functional or non-functional. Given only these two choices, data requirement details are typically included as part of functional requirements. Some may be recorded separately as business rules. By focusing on data fundamentals for information systems, this series hopes that business analysts will be better able to recognize data-specific needs and document them accordingly. 

Have you ever wondered how global a career in Business Analysis might be? So, you roll up to your desktop or laptop every morning in an office or these days mostly likely at your workspace at home. You check your emails, plan the day, speak to your colleagues and manager, attend meetings and work your BA magic all within the boundaries of your project, client or organisation. Everyone speaks the same language and I’m not talking about English or Spanish, I mean tech speak, industry speak and BA buzz words like ‘moment of truth’. But what if you were to take your desk and move it halfway across the globe to a different country and time zone? Would organisations even face the same challenges most BAs are helping to solve and would teams use the same techniques to help solve them? I can answer that question with a resounding ‘Yes!’

Agile project management describes an iterative approach that targets project management in a given setup. Usually, Agile project management focuses on subdividing large projects into smaller and more manageable tasks. These tasks are completed in some sort of short iterations that cover the entire project life cycle. 

If your team takes advantage of agile methodology, it will have higher chances of finishing the work faster, optimizing the workflow, and adapting to ever-changing project requirements. 

Agile project management enables your team to re-evaluate every single task it is undertaking. The Agile project management also lets the team members adjust in increments to keep up with the shifting customer landscape.