Entries for 'adrian'

Anyone perusing the computing rags (or their online equivalents) will no doubt have noticed that this year's big thing for applications development is a combination of Cloud Computing and Software as a Service (SaaS). I'll talk about Clouds in a future blog, as I want to concentrate on the SaaS phenomenon today.

Businesses cope with manual, repetitive tasks to get the job done. Email, conference calls, and "walking the cubes" are too frequently the process for requesting information, getting approvals, and checking project status. Time and resources are wasted, errors abound, and everyone is less productive.

Automating these everyday business processes is the way to improve productivity and gain efficiency. Traditional Business Process Management (BPM) systems can provide a solution, but the cost and complexity to implement simple processes is often too expensive for many business units.
 

For almost every analyst, the day comes when you write a set of requirements that causes engineers to bemoan a recent development project that they just coded. "If only we'd known that you wanted to build this, we would have made the last project more flexible. Now we've hardcoded in changes that will take days to rebuild."

The title of "Business Analyst" is one of the fastest growing in the IT industry. In fact, the United States Department of Labor projected a 29% increase in computer systems analyst employment by 2016. There are many resources available that explain what a business analyst is, often in terms of comparing the responsibilities of an analyst to those of other team members we're more familiar with, like project managers, software testers, and systems architects.

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.

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.

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.