From a developer's standpoint, few things are more frustrating than having to make lots of calls and research to learn what to create because the requirements are ambiguous. From an analyst's view, few things are more frustrating than having your requirements misunderstood. Yet so often, requirements are ambiguous to their readers, despite the writer's best efforts.

A process is a series of steps completed to achieve a particular result. It is hard to imagine a process improvement effort that doesn’t start with a focus on that result with a question like “What is the purpose of this process?” - whether the customer is actually engaged or not. Sometimes we have a strong sense that our product or service is good. Sometimes we choose to “get our own house in order” before we step outside the organization. Sometimes we base the result on a prescription provided by the customer. However, sometimes, our focus may be misdirected to how we do the work without considering why it is done in the first place...particularly where slick new technologies are involved. In any case, without actually engaging the customer, we can’t really know how well the process is working to provide the customer with what the customer needs or wants.

Quality requirements contribute to the success of agile and traditional project management projects. The requirements definition process followed in a traditional project management framework and the features-based storyboarding that is typical of agile approaches are different, but they also have many similarities. The actual process used to define and gather requirements may be different, but the criteria for quality requirements remain constant. What are these similarities and differences in the process of gathering requirements? What happens to the role of the business analyst in an agile environment?

I am not sure if there are many other fields in corporate America that require the finesse necessary to execute the professional pushback as greatly as business analysis. Just by the shear nature of what analysts do, we are constantly uncovering inefficiencies and making recommendations for improvements or enhancements. Sometimes those recommendations are system-focused but they can also be people and process focused.

If requirements management practices were songs entering a popularity contest, requirements validation would hardly be a favorite contender. It's easy to understand why: validation is usually a tedious, time consuming task, and, as with nearly every quality control activity, it is supposed to reveal defects, going against our natural desire of being right, not making mistakes, and singing in tune.

Agile development practices introduced, adopted and extended the XP-originated "User Story" as the primary currency for expressing application requirements within the agile enterprise. The just-in-time application of the user story simplified software development and eliminated the prior waterfall like practices of overly burdensome and overly constraining requirements specifications for agile teams.

However, as powerful as this innovative concept is, the user story by itself does not provide an adequate, nor sufficiently lean, construct for reasoning about investment, system-level requirements and acceptance testing across the larger software enterprises project team, program and portfolio organizational levels. In this whitepaper, we describe a Lean and Scalable Agile Enterprise Requirements Information Model that scales to the full needs of the largest software enterprise, while still providing a quintessentially lean and agile subset for the agile project teams that do most of the work.

Most analysts are introduced to SOA in one of three ways; two of which are potentially painful and one of which is actually useful. I’ll let you decide which you would prefer.

The path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.

Babies and Business Analysts go through four stages, as they open their eyes and see. 

In Stage 1, with eyes closed, BAs are blind to their organization’s mess.

In Stage 2, as their eyes begin to open, BAs see in black and white: a single process step, template or isolated requirement.

In Stage 3, the mobile movement of the outside world attracts and delights them: industries, methodologies, collaborations and emerging trends.

In Stage 4, they strengthen their muscles: the analytical and creative skills used to facilitate organizational futures and protect their parent enterprise in this new economic climate.

In the twenty-first century, business processes have become more complex; i.e., more interconnected, interdependent, and interrelated than ever before. Businesses today are rejecting traditional organizational structures to create complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers, and partnerships with key political groups, regulatory entities, and even competitors.