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?”