In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.
While working on a Business Architecture effort several years ago, I collaborated on developing a new internal standard for business process and business capability description. From my perspective, a business capability is the required function or desired service that a business unit performs and the business process is the set of methods employed to realize the business capability. Business capabilities and business processes can be described as current or future state. Their description can also be scaled for strategic or tactical objectives.
This article will present an approach for documenting and aligning business capabilities, business processes, and functional requirements by integrating two distinct tools that leverage robust repositories and object metadata.
Software production has become one of the key activities of the industrialized world. Software applications are now the driving force of business, government operations, military equipment, and most of the services that we take for granted: electric power, water supplies, telephones, and transportation. Most major companies and government agencies build or commission new software applications every year. But software development and software contracts have been very troublesome. Cost and schedule overruns are common, and litigation for software problems is a frequent outcome. Successful development of large software projects is so difficult that significant percentage of large systems greater than 10,000 function points are canceled and never completed. One of the major challenges of software cost and schedule estimation is “sizing” or predicting the amount of source code and other deliverables that must be built to satisfy the requirements of a software application. Sizing is a critical precursor to software cost estimating whether estimation is done manually or by means of a commercial software cost estimating tool. For software applications that are similar to existing applications, size can be derived by analogy to the existing packages. When the software application is a new kind of application then sizing by analogy is not a feasible approach. For much of the history of the software industry, sizing was considered a very difficult and intractable problem. Sizing is still difficult, but over the past 30 years an interesting new methodology for dealing with size prediction has been developed based on the use of the function point metric. This new methodology has the advantage that it can not only predict the volume of source code, but also the volumes of planning documents, specifications, user manuals, test cases, and even the probable number of errors or bugs that might be encountered.
Author: Capers Jones is the President of Capers Jones & Associates LLC. He is also the founder and former chairman of Software Productivity Research, LLC (SPR), where he holds the title of Chief Scientist Emeritus. He is a well-known author and international public speaker, and has authored the books “Patterns of Software Systems Failure and Success,” “Applied Software Measurement,” “Software Quality: Analysis and Guidelines for Success,” “Software Cost Estimation,” and “Software Assessments, Benchmarks, and Best Practices.” Jones and his colleagues from SPR have collected historical data from more than 600 corporations and more than 30 government organizations. This historical data is a key resource for judging the effectiveness of software process improvement methods. The total volume of projects studied now exceeds 12,000.
Copyright * 2008 by Capers Jones & Associates LLC. All Rights Reserved.
The Volere requirements techniques were developed to answer the need for a common language for discovering requirements and connecting them to solutions. The language needs to be understandable by business people, customers, business analysts, engineers, designers, suppliers, testers or anyone else whose input is needed. All of these people have different skills and, not surprisingly, different views of what is important. A language intended for all of these people must recognise the differences in peoples’ viewpoints and yet have a consistent way of communicating and tracing the relevant knowledge. This realisation that requirements is a socio-technical discipline has a strong influence on the development of the techniques.
Author: Suzanne Robertson & James Robertson, The Atlantic Systems Guild
"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.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: