A long time ago, before Business Analysts existed, it was believed that people in the business would be able to define their own requirements.  When a business department wanted to have a new piece of software, they would go to the IT department and the developers would ask them what they wanted. The business people would express this as best they could by writing down lists of things and having meetings to explain them, and then the IT department would build or buy whatever they seemed to want.
 

Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.

The business analyst's job has changed this year -- and so have the critical skills that companies demand. New research shows that while communication is still key, knowledge of Lean and Agile methods is a must-have as well.

In Part 1 of  this article, I talked about the new skills and attitudes business analysts need to bring to agile development... Now it's time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let's take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.
 

Although it may seem obvious that the User Interface (UI) directly impacts usability, and therefore satisfaction, Business Analysts often find themselves focusing on functional requirements to ensure end user satisfaction. Mainly, this is due to the non-functional requirements, like usability, being dictated by existing technology or process within the organization. However, research into mobile user interfaces is placing the focus back on the usability requirements as the main driver of user satisfaction.

"How do I move into the field of Business Analyst?" or "How do I move up within the field of Business Analysis?" These are common questions heard in today's job market. Whether you are a programmer, a software engineer, a business subject matter expert (SME) who wants to transition into a Business Analyst role,a recent graduate who is trying to determine how to break into the B.A. job market, or your company just one day changed your title to Business Analyst,this article contains a list of 12 things you can do that will help you connect with the vast community of knowledge and resources.

Much of the current buzz about SOA has been focussed on the technology (inevitably Web Services) or the importance of reusability. However the real value of SOA is in the improvement to processes and ways of working that reflect the alignment of an organisation with its customers and suppliers.  The approach we favour is one that begins by aligning the business and technical understanding of the concepts of SOA, from both the business process and technical architecture perspective.
 

With current economic conditions, companies are striving to do more with fewer resources, both human and material. So it should be no surprise that the fusion of business processes and practices is both relevant and necessary. Over the past two decades business methodologies and corporate programs have established track records that demonstrate performance and quality improvements within their organizations.

When the first flowcharts were applied to manufacturing processes, they followed the flow of a single part through its manufacture.  They displayed, in sequence, the steps it took to make the part and they made sense.  They were easy to visualize, easy to follow, easy to work with, and they resulted in millions of dollars worth of productivity gain. 

This same concept was applied to information process charting in the 1940’s.  However, rather than following a single flow, multi-flow process charts were used.  They showed all of the records in a business process in order to make clear the exchange of information between records.  Once again the effort generated millions of dollars worth of productivity gain.

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.