Given the speed of change, it is really tricky to predict what trends will grow in popularity or relevance. I am sure whatever emerges will seem obvious in hindsight, even if it would have been difficult to foresee. Yet, I have always thought that making predictions has a useful place in that it creates a conversation and it creates debates. So, what follows is designed to provoke discussion, and is intended to represent ‘potential trends to watch’.

Are we really trying to promote teamwork or is this nothing more than the latest corporate fad that is being implemented more for public relations than anything else? Let's hope for the former and not the latter. Teamwork is a powerful concept, particularly when there is anything of substance to be done.

Agile adoption is not ‘a walk in the park’! Agile is a framework of lightweight methodologies aimed at fostering flexibility and evolved as a proactive means to challenge the conventional mode of software development (SDM). The Agile methodology relies upon an iterative and incremental process to accomplish the project objective. Agile is a sharp contrast to the traditional sequential developmental methodology that lacks the ability to adapt to challenges through the lifecycle of projects.

As, more and more companies start to embrace cloud technology, it is vital that business analysts are able to identify the cloud service that is required to meet business requirements. As business analysts, we are often criticized for not getting involved in the technical side of things. However, it can be difficult to make decisions on technical side of things, if you don’t understand the language that is used in this space.

I don’t know how many articles I’ve read where the author states requirements should be “what” the user/client needs, not “how” to deliver the solution. They say “A requirement should never specify aspects of physical design, implementation decisions or system architecture”... In my humble opinion, every requirement, even the business level needs, goals and objectives, are just the start of a long march to a solution.

Enterprise Agility means the ability to adapt easily to change. In the business perspective, agility refers to a distinct quality that allows institutions and corporations to respond rapidly to change. It is the ability and capability of a system to respond rapidly to a certain modification by adapting its inceptive and stable configuration.  Agility is also viewed in relation to the results of organizational intelligence. It is the aptness to react successfully to the emergence of new competitors, abrupt shifts in the overall market conditions, and adaptation of industry-changing technologies that are based on the degree of agility in the organization.

User stories are a simple, yet effective way to communicate how a user or customer employs a product. But writing user stories that help a team build great software can be challenging. The article shares five common user story mistakes and how to overcome them.

The purpose of this article is to explore feature files. Feature files are documents that contain those Gherkin scenarios & requirements – they can be very useful to teams working on BDD projects. Feature files may be a key deliverable for BAs.  Feature files are where BAs store requirements & can create the bridge between requirements and automated tests (more on that later).

Imagine that a business analyst has been assigned to write the requirements for a new system replacing the company’s legacy CRM (customer relationship management application).
After mapping out the as-is process at a high-level, the BA’s stress level starts to go up. “There are three complex modules in this system, and so many details about the as-is state that I still don’t understand! The legacy system barely has the original requirements documented, with plenty of change requests implemented later without proper documentation. How am I supposed to finish my deliverables on schedule and without mistakes given my limited knowledge of how the system being replaced works?”

A BA walks into an elevator, is joined by an executive, and suddenly the executive asks the BA, “So, what are you working on these days?” (Sounds like the start of a joke ...)  Most business analysts, due to their project success focus, think of requirements management when questioned about their work. So the BA responds by describing the features of a business solution that the BA is currently working. The BA seldom mentions the associated business benefits with the work (i.e. why the work is vital to the business). Unfortunately, the BA ignores the first rule of conversation: know your audience. The executive asking the question is more likely to understand and be interested in the business value provided by the work, rather than the solution features.

Agile Manifesto is a means to achieve the end objective through ‘best practices’ that crystallize into an approach that efficiently resolves the competitive stand-off. Thus the Manifesto is a subset of principles that provide a working framework to attain Agility. The following are high-impact Manifesto principles...

Estimating is one of the most controversial subjects in project management. There are some people who have turned the subject into a cryptic science involving esoteric techniques. Estimating is simply the process used to determine the amount of effort and cost required to implement a project, in part or in full. It is important to acknowledge that...

 In this article we look at some quality attributes that are particularly vital to explore when specifying requirements for embedded systems projects. Quality attributes for embedded systems can be much more complex and intertwined than those for other applications. Business software is generally used in an office where there’s not much variance in the environment. In contrast, the operating environment for embedded systems could involve temperature extremes, vibration, shock, and other factors that dictate specific quality considerations.

A requirement is “a condition or capability needed by a user to solve a problem or to achieve an objective” (AKA a goal). Thinking in terms of problems and goals thus is a core competence for the requirements engineer. But what in fact is a problem or a goal? This may seem to be a rather philosophical question. As requirements engineers we should be quite specific on this point as the problems and goals of our clients are the raison d’être for our work.

The experience age will force the business analyst, more so than ever, to be closer to business. The focus will have to move from how the IT landscape looks at the architectural level, to how it can be best utilised to provide the most compelling and efficient customer experience.  The success of business will now be determined by how well the customer journey and user experience has been translated to offer real and/or even perceived value for money through ‘virtual experience’.  It will be difficult for the business analyst to be a credible advisor to business without understanding the customer’s needs.