As the battle between waterfall and agile rages on, organizations continue modify their approach to software development. Very few move directly to a pure agile approach. Instead, they pilot agile processes, create project selection criteria for agile projects, they shorten release times, minimize project documentation, and many are creating hybrid approaches blending both Waterfall and Agile.
As software development methods evolve, the BA role and their requirement processes come into question. Organizations begin to ask, “How do BAs fit in?”
Some have BAs do the documentation and for Agile projects what gets documented is anything from photos of sticky note user stories, to formalized user stories with acceptance criteria, to the same requirements documentation as in waterfall but done at the end vs. beginning of the implementation.
Where I see the common thread in the BA role is in usage of key techniques needed to understand the business need and maximize the value the solution brings. Regardless of the methodology, roles, and deliverables, the goal of every project is to deliver value to the stakeholders and organization.
In order to deliver value, project teams need a shared understanding of context, processes, needs, wants, priorities, etc. The elicitation and analysis techniques used to build this shared understanding are the common ground between approaches like Waterfall and Agile.
We can share!
This final part of the article compares and contrasts three more pairs of use case model elements, and suggests that use cases are not instantiated in their capacity as included, extending and generalization use cases.
EXTENSION USE CASE VS. OPTION FLOW
The ‘extension use case’ concept is explored in  and in section ‘Instantiating Included and Extending Use Cases?’ below.
The ‘option flow’ idea is introduced in  and further referenced in [1.3].
Often a Business Analyst is considered to be a liaison between IT and Business units to ensure that the “requirements” as set out are met. This might be a starting point for a novice Business Analyst; however the role becomes stagnant if the BA does not explore the Businesses, processes within the organization to understand the enterprise as a whole and help in making recommendations that helps the organization advance financially or have an edge over competitors.
Sometimes it is also a good idea to understand the business models of the competitors to have a fair view of what the customers are really looking for in the competitor’s products. I am not saying that a comparison must be drawn between the Business competitors as the strategies, goals and structures are entirely different. An overview of the market segment trying to understand customer inclinations (irrespective of the fact whether a customer uses your product or the competitor’s product) is necessary for a Business Analyst to get the “overall picture” before making recommendations at the Enterprise Level.
As you gain experience within the organization with regards to the processes, models, business units it is imperative that the Business Analyst works hand-in-hand with any of the business owners or a business unit to foresee the market trends, changes and understand the customer impulse.