"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."
In this article Ellen covers a number of agile requirements topics including:
“The biggest risk to your company is not being able to change fast enough… Business Rules are the answer.” …Ron Ross I am a great appreciator of Mr. Ross. He has written extensively on the topic of Business Rules, offers excellent training on the subject, and is the keynote speaker at each year’s International Business Rules Forum. I would like to start my own article on Business Rules with an ‘icebreaker’ he used on a seminar I attended. Consider the sport of American Football. Some aspects of the game are very stable, some less so, and some not necessarily stable at all.
Author: David Wright
As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems (www.sparxsystems.com) for a number of years. In that time I’ve spent considerable time and energy trying to get our business analysts to do the same. While I’ve had some success I must admit it’s been an uphill battle. I suspect this is partly because EA is often seen as a technical person’s tool. And that’s not altogether surprising.
So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.
The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.
In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices
A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time. After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no. Let’s see this concept in practice in the “Requirements for My New Car”: a fable.
Have you noticed the examples of requirements elicitation on my blog? In one case, I had a bit of a contest, using a game to elicit information. You can see this technique by looking in the category Online Game on the blog. Then I had a survey to elicit information. You can see that survey by looking in the category Survey on the blog. Today I am going to use the information from the survey to show you another technique you might use when developing requirements. That technique is writing Personas (or Personae for you Latin fans). You write a Persona when you want to understand your customers better. This Persona is a story you will tell about a typical (but not real) customer. The Persona is a composite story about your typical customers, made very lifelike.
THE ANALYST (aka, Systems Analyst, Systems Engineer, Systems Architect, Business Analyst) - requires specifications about the end-User's information requirements in order to design a system solution. This is normally based on a definition of the user's business actions and/or decisions to be supported. Following the system design, the Analyst produces the specifications required by the Programmer and DBA to fulfill their part of the puzzle. From this perspective, the Analyst is the translator between the end-User and the Programmers and DBAs. Each party has his own unique perspective of the puzzle and, as such, requires different "specifications." To compound the problem though, the role of the Analyst sharply diminished over the years, leaving it to the Programmers to try and determine what the end-User needs, a skill they are typically not trained or suited for.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: