Tag: Development

Requirements Gathering in a Flat World

Written by Darren Levy on September 29, 2009. Posted in Articles.

In his 2005 bestseller The World is Flat, New York Times columnist Thomas Friedman famously proclaimed that advances in global communications technology had essentially rendered the world flat. By this he meant that the massive investment in communications infrastructure that fueled the dot-com bust has, as a virtuous by-product, allowed a new generation of companies to leverage cheaper resources abroad.

And has it ever!

The ubiquity of persistent Internet access has enabled a new generation of companies to leverage resources – be they human or IT-based – wherever they might be physically located. Regardless of how you feel about the political implications of offshore outsourcing, it’s clearly no passing fad.

It wasn’t too long ago that developing software via offshore outsourcing belonged solely to the province of large enterprise organizations. This of course is no longer the case as even the smallest companies have come to rely on distant software development teams in Eastern Europe, former Soviet republics, and Asia. In fact, this ability to instantly tap cheaper development resources and expertise has directly contributed to a burst of innovation, as smaller companies are able to level the playing field with their larger enterprise counterparts.

Yet this opportunity also comes with some thorny strings attached – any short term savings realized can be quickly offset by poor requirements definition and gathering practices. As business analysts well know, clearly articulated software requirements represent the foundation of any successful software project. Indeed, the reason why so many software projects continue to fail is precisely because not enough attention is paid to this critical first step in the software development process.

Communicating and managing software requirements is of course challenging enough even when all your team happens to be situated in the same location. But when working with a distributed team, many of whom don’t even share a common first language, the potential for errors grows considerably. And thus, any savings realized by cheaper resources is suddenly squandered. Worse still, time is wasted, morale suffers, and the project team is forced to shift into “fix-it” mode.

On-Demand Apps Grow Up

When Salesforce.com was founded in 1999 by former Oracle executive Marc Benioff, the notion of applications hosted “off-premise” was still something of a radical idea. At that time, there were still a number of barriers to widespread adoption: application performance, security assurances, and bandwidth constraints, to name but a few.

Just 10 years later, practically every major software category now includes a healthy ecosystem of on-demand solutions. Not only has the supporting infrastructure matured with offerings like Amazon’s EC2 cloud platform – allowing software providers to more easily configure their application in the cloud — but the next generation of on-demand applications are pushing the envelope in terms of what can be delivered through a browser. More and more, these applications feel and act like traditional desktop software. But of course, they can do so much more because they are intrinsically connected. Now, every on-demand application has the potential to become a dynamic collaboration platform that succeeds in bringing all project constituents to the table. And, as more on-demand application developers create and publish their APIs, they can be integrated into other facets of the software development process.

But it’s this idea of connectedness that’s so powerful when it comes to keeping distributed teams marching to the same beat. Business analysts are not just responsible for defining requirements but also for ensuring that they’re properly communicated and correctly applied. While large enterprises might have the luxury of a robust requirements management tool at their disposal that incorporates collaboration (and surprisingly, only a small percentage of these enterprises have adopted these types of solutions), the average small to medium enterprise does not. Instead, most of these companies use some combination of Word, Excel, and email to define and communicate requirements to their development teams. Because these tools are disconnected from one another, the potential for miscommunication is an endless challenge. And when those development resources are located half a world a way, it’s not a question of if something will go wrong but rather when.

So what’s a budget-minded business analyst working with a distributed development team to do?

Requirements Outlook? Mostly Cloudy.

In many respects, business analysts can find inspiration in the latest hype cycle: social media. Social applications like Facebook and Twitter have reshaped our personal dialogue and communications framework. And aspects of these sites will likely transform the way we think about software requirements.

For better or worse, we are in constant communication with our own personal circle of contacts. Anyone who has been part of a software development team understands how important it is to be in regular contact with the rest of the team. From the beginning of a project (i.e., defining use cases) through the implementation phase (i.e., bug tracking), persistent communication is the new Critical Chain. Put another way, when you can’t all be present for the daily stand-up meeting, how do you ensure everyone is on track?

There are three key ways that migrating the requirements gathering process to the Cloud will help business analysts get better results from their distributed development teams:

Collaborate in Real Time, in Context. Email is a terrific communications tool. But it’s asynchronous and often detached from a larger context. This becomes especially problematic when multiple teams are working on different aspects of the same project. By unifying the requirements process in a hosted environment, distributed teams can collaborate in a meaningful way and identify potential problems before they get out of hand.

Visualize the Workflow to Mitigate Language Barriers. One of the most vexing challenges that business analysts face when it comes to working with offshore developers is communicating across multiple languages. There are the obvious spoken language barriers to overcome. But more often it’s the nuance and culture of language that presents the most significant obstacle. Because business and software requirements are technical in nature, employing a visual language to communicate requirements becomes a necessary complement. As traditional requirements gathering tools move to the Cloud, the ability to clearly represent business requirements in a visual manner (i.e., use case scenarios, parking lot diagrams, etc.) will help keep all project constituents on track.

Visibility for All, Across the Entire Requirements Spectrum. No software developer should be an island to themselves. Even though two developers might be working on two discrete and unrelated tasks, it’s still vital that they understand the underlying business requirements that are driving the project. By standardizing the requirements management process in the Cloud, the business analyst can provide all of their team members with the “situational awareness” they need to understand how their software will be used.

In Flat We Trust

The world is indeed becoming flatter by the day. Just as the path of water naturally finds the path of least resistance, free markets will invariably gravitate towards the most cost-efficient resources. However, even with all of Friedman’s optimism regarding the potential rewards of offshore outsourcing, he also goes on to warn us: “In this era of mounting complexity with more people, systems and products entwined in a bewildering web of global networks, explaining is an enormously valuable skill.” In a sense, that is exactly what software requirements are all about: explaining. And explaining becomes all the more important when teams are fragmented by geography, culture, and language.

Don’t forget to leave your comments below

Darren Levy is the founder of GatherSpace.com, a provider of on-demand requirements management solutions based in Los Angeles. Email him at [email protected].

Building and Managing a Requirements Center of Excellence. Part I.

Written by Tony Higgins on September 22, 2009. Posted in Articles.

Maximize Application Quality; Minimize Cost and Time-to-market.

The phrase “the world runs on software” is almost cliché now. Everyone’s life is a daily testament to this adage. Software is ubiquitous and is without question business critical. Virtually every modern-day business has some, if not all, of their business-critical functions implemented in software. In the software game, if you “get it right” the benefits of implementing business in software can be tremendous. If you don’t “get it right” you can find yourself out of business.

Errors in a software development projects have to be confronted if you are to deliver a product with any degree of quality – it isn’t a matter of “if” you fix them, it’s a matter of “when”. Most errors in a software development project originate very early in a project during requirements definition – 68% in fact [Standish]. This represents a huge opportunity to improve software project performance since it is well known that errors are exponentially cheaper to fix when detected earlier in the development life-cycle. But how do we find errors at this early stage and/or prevent them altogether? How do we unambiguously communicate the requirements to developers, testers, and support personnel in a language they understand? Once these questions are answered, how then do we make this a core-competency of our software development capability across all projects? This is what a Requirements Center of Excellence (CoE) is intended to address. It is an investment to capitalize on what is one of the largest opportunities related to software development, and therefore business, today.

In short, a Requirements CoE is the consolidation and centralization of Requirements expertise, knowledge, process, and tools, so that it may be continually improved and leveraged to maximum advantage across all projects in an organization. With a Requirements CoE, valuable new lessons from one project, instead of taking months or years to propagate “organically” can be quickly leveraged across the organization thereby driving rapid improvement.

Just some of the benefits from implementing a Requirements CoE include:

Cost Savings. Early error detection and correction dramatically reduces rework

Efficiencies. Consolidation of disparate requirements initiatives

Reduced Time to Market. Reduced rework results in finished products sooner

Product Predictability. Early error detection reduces risk, improving predictability

Quality. Higher quality requirements and automatically generated inputs for Developers and Testers means less rework and higher quality results

Rapid Improvement. Requirements investments are leveraged across the organization much faster

One of the most promising aspects of a Requirements CoE is that it allows for consistent measuring performance from the perspective of business and end-user results across the organization – not just measuring systems and components at a project or departmental level. With all projects addressing requirements with a consistent approach, common metrics can be established and directly related to business objectives.

A Requirements CoE can be built incrementally with return on investment measured at every stage. For the more risk-averse you can start small, consolidating and leveraging existing requirements resources, and expand as the value is proven.

A Requirements CoE can dramatically reduce the cost of software development for the organization and provides mechanisms to make the benefits sustainable.

What is a Requirements Development Center of Excellence?

A Requirements CoE is an internal group focused on optimizing the quality of requirements produced for all software development projects, ensuring that the requirements reflect true business needs and that they can provide the basis for efficient and effective product development.

The types of activities a Requirements CoE performs include:

Requirements tool evaluation, standardization, purchase for the organization
Requirements process definition, standardization, and tailoring
Requirements Metrics definition, automation, collection, storage, reporting
Requirements Training and mentoring services for company staff
Project “Startup” services (assess, recommend tools, process, training, mentoring)
Requirements component reuse storage, repository, cataloguing, and guidance
Requirements model review and consulting services for projects
Requirements guidelines, standards, and best practices
Representation in industry Requirements community
(a more comprehensive list is provided later in this article)

Through the Requirements CoE approach, project teams are able to take advantage of all of the expertise, process, toolsets, and best practices the Requirements CoE has developed and consolidated. This section provides an overview of the Requirements CoE and examples of the services it can provide. The next section takes a closer look at the business value of implementing a Quality CoE

Traditionally every project team is an island with its own staff, tools, and practices. The Requirements CoE model centralizes the expertise and processes, brings Key Performance Indicators (KPIs) to requirements initiatives, and can actually reduce total headcount needed to develop, test, and deliver higher quality applications.

Checklist:

You Should Transition to the Requirements CoE Model soon if you have

Chronic overruns of project budget or schedule, or regularly change scope of application to meet targets
Inability to estimate the cost and schedule impacts of proposed changes during development
Different approaches to expressing requirements from project to project
Project success seemingly dependent on involvement of a few key individuals
No perceptible improvement in predictability of projects from one to the next
Applications that are difficult to modify or customize, and expensive to maintain
Incomplete or inaccurate technical documentation for an application

How a Requirements CoE works: Five Simple Examples

The examples below contrast how an organization might respond to real-world situations with and without a Requirements CoE.

Example 1: A key employee with several years’ experience in business analysis leaves the company mid-way through a critical project

With a Requirements CoE.: The company’s best practices for Requirements Development are defined and shared through the Center of Excellence. All Requirements Center models and sub-models developed by the Analyst over the years are immediately available from the Requirements repository maintained by the Requirements CoE. The Requirements CoE can provide short-term relief to the current project with Business Analysis skills, and/or help ramp up a replacement with any training and mentoring that may be required.
Without a Requirements CoE. The project scrambles to find a replacement and then ramp up that replacement on the manner in which this project works with requirements. Information, notes, emails, and any other bits of information found are gathered in an attempt to reconstruct requirements in their current state. Co-workers and past colleagues are polled to find historical knowledge from the employee.

Example 2: Acquire a Company

With a Requirements CoE. All projects of the “host” company develop requirements in a consistent and effective fashion in accordance with the company’s best practices for Requirements Development as defined and shared through the CoE. CoE experts assess the acquired company’s Requirements Development capabilities and make recommendations for transition and any modification to existing assets (eg. Project Start-up packages, courses, packaged services, etc.). Training and mentoring packages of the CoE are used as part of a transition plan to educate staff of the acquired company. Project Start-up packages, maintained and delivered by the CoE, are used to launch new projects within the acquired company or as a basis to plan transition of projects in progress, where appropriate. A focused transition with well-defined “end-state” where all expectations of host and acquired staff can be managed effectively. Acquired staff gets a sense they are transitioning to a well-managed environment.
Without a Requirements CoE. Host organization differs in Requirements Development approach from project to project, with low level of consistency. Not clear what acquired company should transition to, if to transition at all. Result is perpetuating acquired company’s requirements approach thereby creating yet another “stovepipe” in the organization, inhibiting integration of the acquired company and the efficiencies that should have been gained because of it. With no clear “end-state” for the requirements discipline the expectations of acquired staff are difficult to manage and they lack a sense of moving to something better. Instead they have a sense of being assimilated into a chaotic environment. Morale diminishes among the acquired staff increasing turnover, reducing productivity, and increasing risk of failed acquisition.

Example 3: External party (customer, prospect) to review or audit software development capability.

With a Requirements CoE. Requirements Development process including best-practices, sample artefacts, templates, guidelines are maintained by the Requirements CoE and made accessible to all projects. Project performance measures collected analyzed and reported on by the CoE are also available. Any mappings of adherence to industry models (CMMi, ISO, etc.) are also be maintained by the CoE. All this information is available for review by the external party and can be explained and discussed with experts from the CoE. Projects in progress can be shown to adhere to the standard process and any can be chosen as an example for further examination.
Without a Requirements CoE. An effort is launched to canvas projects seeking the “nicest” examples of requirements artifacts. Any process descriptions are similarly gathered or created in order to explain how requirements activities are performed. Directories for old projects are scanned, again seeking good examples of requirements artifacts. Metrics on performance are gathered where they exist, and attempts made to normalize and reconcile them in order to extract some meaning.

Example 4: A new, business-critical project initiative is being considered and accurate estimates of time and cost are required in order to make a decision to proceed.

With a Requirements CoE. Requirements models for past projects in the repository are examined for reusable models and sub models. Metrics on past project performance are analyzed. A high level, abstract Requirements Center model is created and supplemented with any reusable sub-models found. This model, along with performance metrics gathered, is used as key basis for estimating the new initiative.
Without a Requirements CoE. Pull most knowledgeable, senior people from current assignments together and collect subjective impressions from past projects of similar nature, magnitude and complexity, if they exist. Estimate for new initiative is based on these impressions and personal experience.

Example 5: A new project is being launched, and the “environment” consisting of process and tools needs to be established.

With a Requirements CoE. The Project Manager notifies the CoE of the new project. Experts from the Requirements CoE deploy the “Project Start-up” packaged service. They assess the project to deduce best fit, given project type, complexity, duration, budgets, people, etc. CoE experts deliver training and mentoring, deploy and configure the toolset, and put process in place. The CoE experts assist with project launch and deliver mentoring with emphasis during early stages of Requirements Development, ensuring staff are proficient with process and tools. Initial artifacts are reviewed by CoE experts to help staff converge on the optimal solution. CoE experts are involved in every major project review and are on call to provide “Just in Time” mentoring and assistance. CoE experts liaise with tools manufacturers as “single point of contact” for special requests and support on behalf of all projects.
Without a Requirements CoE. The Project Manager tries to secure time with process “experts” from wherever they may be in the company. Experts and senior project staff do “process engineering”, typically under project budget, to identify desired approaches, tools, templates, guidelines, etc. for the project. The results of this activity are highly dependent on the personal experience of the individuals involved. The project then puts all in place, must devise means of educating staff, acquires and deploys/configures tool(s). Interfacing with vendor is often done by designated project staff. When issues arise with process, tools, advice is sought in informal manner from whatever source might be available.

Start Small and Grow Organically

One of the key advantages of a Requirements CoE is that it can be established incrementally and show incremental returns on investment. A Requirements CoE can be built on a small scale initially with minimal capital expenditure and you can scale up its resources, services, and capabilities incrementally as its value is proven.

Initially the Requirements CoE could focus on the standardization of requirements artifacts including notations and formats. This can be followed by, or deployed in conjunction with, standardization of tool support for defining requirements. In time, the process by which requirements are developed based on the notations and automation can be formalized and tuned. The standardized process would include aspects made possible only by automated tool support, such as immediate validation of requirements using simulation and testability assurance. Still later a centralized repository for requirements artifacts to facilitate reuse could be added followed by a formal requirements metrics program to provide the basis for continual requirements improvement.

Therefore the CoE can grow both in capability and breadth of adoption across the enterprise at a rate that fits the constraints of the organization.

Requirements CoE Resources and Services

The Requirements CoE has the potential to become a competitive advantage for any company whose business relies on software. Since requirements are the cornerstone of the software development process with all other disciplines dependent on its artifacts and with 68% of all errors being introduced at this point, there is tremendous potential for cost-savings and quality improvement. The nature of the services that can be provided by a Requirements CoE include:

“Project Start-up” Services with Respect to Requirements

Leverage the growing Requirements Development knowledge and experience base
Provide expert assistance in assessing and devising best approach for tools, process, and training/mentoring needs for the project
Assist in setting up environment including project guidelines, standards, templates, and other assets
Deliver training and mentoring in Requirements Development process and tools

To be a Cross-product/divisional “Communication Hub” for Requirements

“harvest” business assets and make reusable
- Business cases and studies to make it easier for other divisions to adopt
“harvest” technical assets and make reusable
- Best practices in Requirements Development across projects
- Reusable Requirements components
- Reusable Requirements Training components
Establish mechanisms to foster communication in Requirements Development
- Newsletters, bulletin boards, interest-group meetings

Requirements Development Tool Expertise

Single point of liaison with Requirements Development tool vendor. Promote organization’s interests, enhancement management, beta participation
First-line support for Requirements Development tool
Experts in tool configuration for specific project usage and application
Development of, and repository for examples templates that support process
Best Practices in tool usage for specific applications

Requirements Development Process Expertise

Generation and maintenance of standard Requirements Development process
Expertise to tailor and adapt the standard process to suit specific projects
Collection of empirical data and metrics to facilitate continual process improvement
Expertise to teach and mentor project staff in Requirements Development process

Education and Awareness of Requirements Development to the Larger Organization

In early stages this new discipline will be largely unknown to most. This center should be capable of fielding requests for information and providing introductory education
Should also be in a position to deliver demonstrations, learning sessions, and similar as part of awareness efforts

To Liaise with Industry Associations and Represent the Organization in these Forums

In order to “harvest” best-practices and approaches found by others, and to monitor trends in the discipline
In order to contribute organizational learning

To provide these services the Requirements CoE should maintain a core staff, whose levels will depend upon how aggressively the organization chooses to grow the discipline. Initially this could involve a part-time manager and single domain expert but could scale over time to support an enterprise.

In this article, we have discussed what a Requirements CoE, is and how it works. Stay tuned for next issue’s follow up, on why organizations should adopt a Requirements CoE, and step-by-step lessons on how to build one.

Don’t forget to leave your comments below

Tony Higgins is Vice-President of Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst. Tony can be reached at [email protected].

Intentionally Incomplete

Written by Robert Galen on July 21, 2009. Posted in Articles.

This is my initial blog for BA Times and I’m certainly happy to be joining the community. So, a little about me-

My name is Bob Galen and I’m from Cary, North Carolina. I’ve spent the greater part of 25 years in software development-in roles such as developer, manager, director, project manager, tester, and project manager.

For the past 10 years, I’ve been moving my thinking and practices towards those espoused to the Agile Methodologies. I’ve found them to be the most congruent, humane, and effective approaches for delivering software and I try to share my insights with everyone I meet.

Perspectives – you’ll see a strong skew in my blog posts related to the following topic areas:

Implications of software testing for the BA
Implications of agility for the BA
And leadership and soft skills topics for the BA

So that gives you a feeling for coming attractions. But, enough of that…

A key requirement artifact in the agile community is the User Story. Mike Cohn does a nice job of covering them in his User Stories Explained book. I may go into more definition later on the topic, but I wanted to explore one critical characteristic of the user story now. That characteristic is this –

The user story is intentionally incomplete. Yes, you heard me right. It’s ambiguous. It’s got glaring holes. It fosters questions…lots of them. Those questions come from different perspectives too. The developers will have a different set than the testers. Or the BA. Or the architects. Or even the ‘customer’.

What’s the point of having a requirement that is ill-defined? I’ll tell you. It’s to drive conversation surrounding each requirement from the host of different perspectives needed for their implementation. You see the questions are expected…in fact, demanded in agile teams. There’s the agile manifesto notion of “People and Collaboration over Process and Tools” and the user story is an initiator of this collaboration.

I think of it not as two-way collaboration, but multi-way collaboration. Minimally, when a team member picks up the user story for implementation, they gather in a triad of three primary roles-the development-centric, testing-centric, and business/customer-centric views. They discuss the details of the story from each of their perspectives and refine it.

Not only refine it, but leverage all of the knowledge gleaned so far from previous story development and project execution. That’s a key here. You defer specific definition realizing you’ll gain richer information with each Sprint or Iteration that you execute. So this “working software” knowledge is also spun into the evolution of each user story. Another driver for this is Lean’s Just-in-Time and Just Enough thinking when it comes to software development. It turns out that we’re often quite presumptuous in our software development efforts. We assume that we can predict the future in requirements or design of software or even our planning without first writing some of the software.

That approach perhaps works for simple or by-rote things, but not for complex applications or those that are new, novel, and competitive solutions to our customers’ problems.

For those of you struggling with this conversation-based requirement approach, I’ll leave you with a final thought. Have you ever seen a written requirement drive development and testing work that, when you pulled the two together, the code didn’t match the tests? Of course you have. I’ve seen this occur way too often. So while writing requirements is good and necessary, the user story is perhaps touching on an important but missing element in our requirement elaboration.

To be continued…

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]

How to Make the Most of Project Process Descriptions

Written by Line Karkov on July 7, 2009. Posted in Articles.

Management’s policies on definitions and documentation of project processes is the kind of thing that could convince you that Dilbert’s author (or Dilbert!) may be employed somewhere in your office. However, if you approach it in the right way, project process descriptions will no longer be a tiresome administrative task but can be used to your advantage. First of all, they can be used to clarify expectations in the project team and with other people involved in the project. Second, you will have valuable input for defining and estimating project tasks.

The purpose of this article is to discuss what the business analyst can achieve by taking active part in defining and describing project processes for requirements development and management.

CMMI: A Process Focused Project Model

Capability Maturity Model Integration (CMMI) consists of a number of process areas. Some of the areas are defined on an organization level and set the framework for the individual projects, for example Organizational Process Focus. Others are defined within the projects and the content will depend on the characteristics of the project. Two of the relevant process areas for the business analyst are Requirements Development and Requirements Management. The better the process areas are mastered by an organization, the more mature it is. A mature organization is able to deliver what the customer needs at the time and price estimated. The CMMI model gives you guidance – described as practices – on what to remember and to consider when defining processes within the process areas. What you do when defining a project specific process is describe how you implement the practices from CMMI. This means that you can use any method you prefer, as long as it is compliant with the practices. For example, in Requirements Development one of the practices is “Elicit needs” but this can be done using both an agile or a waterfall approach.

CMMI basically applies common sense in a structured manner. The main point is this: define and plan your process in advance, work according to that process, adjust it along the way, and learn from your experiences the next time around.

What to Include

First you describe the purpose of this particular process. You will do yourself a favour by focusing on the characteristics of the project instead of describing the overall purpose of developing requirements. This will help when you need to determine which methods to use. Your process description should contain the following:

Roles and Responsibilities
Who is involved and how are they expected to contribute? Who has the final word when it comes to prioritizing, accepting and approving requirements? This is important for the obvious reason that stakeholders and end-users will know what is expected of them. But there is another important point. Because you have identified up front who is supposed to participate, you will have everyone involved on equal terms from the beginning. A consequence of not doing this is that you could find yourself favoring groups of end users or stakeholders that are the loudest, are closest geographically to the development team or are in best standing with top management. This can be avoided by identifying your participants at the start and you will develop a “democratic” process for developing and handling your requirements.

Activities or Tasks to Be Carried Out
This is basically just outlining what to do in which order. For example, which method(s) do you intend to use when eliciting needs and requirements? How will you document or model your requirements? When are you done developing requirements? It is a good idea to also define entry and exit criteria for each activity. That is, what is needed in order to perform the activity and when do you know that you are done? This will not only ensure that you achieve what you set out to do but also that you do not overdo it or get lost in details.

How to Approach the Process

The extent of this work will depend on many things. For instance, how experienced you are and how well you know the other people involved. If you have done this many times before, it will just be a formality ensuring that your activities are in line with this particular project and setting expectations straight with the project team, stakeholders and end users. This will probably be something you can sketch out on a napkin during lunch. If you are new to the field, you need to consider how to incorporate best practice or theory from the field.

Create a First Draft

If you are new to the organization or the business area this is a good opportunity to ask around about previous experiences with the same kind of projects, find out what you need to pay special attention to, the relation between the stakeholders etc. This is, in other words, the perfect chance to “stick your finger in the ground”.

Review and Acceptance from Project Team
Before you communicate how you intend to approach the requirements development, it is important to have commitment from the rest of the development team. Also, if you don’t know the team members, this is a way to clarify roles within the project team. When reviewing project processes, be aware of overlap between different process areas. This can lead not only to duplication of work but also to unclear responsibility between project participants. For example, when working with requirements management, you have to be aware of the change management process and make sure that the two process areas are coherent. How to suggest a new requirement to the project will be described in change management, while how to archive rejected requirements would be included in requirements management.

Acceptance from Stakeholders and End Users
It is important that whoever is paying for the party agrees to who should be involved and the extent of their influence. This is probably the closest you get to a guarantee of commitment to the final result of the requirements development. When this is clarified with the project’s sponsor, you can communicate to your stakeholders and end users how you intend to involve them. Acceptance from everyone involved in the requirements development regarding the premises for the task, their role, and when they are expected to contribute is important for full cooperation. When this is settled in advance, you can focus on the actual objectives of the project in the requirements development activities. A good idea is to create a “start kit” for the people you cooperate with on this. It does not have to be more than a brief presentation about the project, their role in it and a list of the planned activities that they have a stake in. You can use this to elicit cooperation by presenting it at a meeting or simply sending it out for information.

Why Even Bother?

The issues described in this article will most likely be issues that all business analysts consider to a smaller or greater extent, more or less explicitly. So what is the point of documenting the processes you work by? First of all, in evaluating your processes you will define learning points and experiences. This makes it easier to improve the quality of your work both in the course of the project and in your next task. Second, it ensures that the methods you choose are tailored to the specific project. No two projects are the same which means that no two approaches to requirements development should be the same. Also, with growing globalization, projects will to a greater extent involve people from various cultures communicating in English, which is not necessarily their native language. This is at least true in my corner of the world, and this increases the need for talking about how we work and why. And how we work and why we work like that is basically what project descriptions is all about.

References: Mary Beth Chrissis, Mike Konrad and Sandy Shrum: CMMI, second edition, Addison-Wesley, 2007
The Texan CMMI guru Tim Kasse has written several books on how to apply CMMI based on his experiences in teaching and assessing CMMI in companies all over the world.

Line Karkov is Master of Science in Information Technology from Aarhus University, Denmark. Since 2007 she has been employed as a business analyst in Danske Bank Group’s internal development department. She works primarily as an internal consultant on large development projects. She teaches internally in development processes. The Danske Bank Group is the largest financial enterprise in Denmark and one of the largest in the Nordic region.

Authoring Requirements in an Agile World

Written by Tony Higgins on March 31, 2009. Posted in Articles.

Equipping and Empowering the Modern BA

The principles of agile development were proven before agile – as a defined approach – became vogue. Agile principles were being practiced to varying degrees in most organizations as a natural reaction to the issues surrounding a rigid waterfall approach.

Every individual task on a software project carries some degree of risk. There are many sources of these risks – some third party component may not function as advertised, some module your work is dependent on may not be available on time, inputs to the task were ambiguous and you made an incorrect assumption when ‘filling in the blanks’, the list is endless. All these risks in the individual tasks contribute to the overall project risk and, quite simply, risk isn’t retired until the task is done. Putting it another way, the risk associated with building something is really only retired when the thing is built. That’s the principle behind iterative and incremental development.

So instead of leaving the first unveiling of a new or enhanced application until toward the end of the project, break it down so that pieces (functional pieces) can be built incrementally. While this doesn’t always mean the portions are complete and shippable, stakeholders can see them working and try them out. This offers several advantages: it retires risk, as mentioned before. It often also exposes other hidden risks. These risks will surface at some point, and the earlier the better. Exposing hidden risk and retiring risk early makes the estimating process more accurate. This increases the probability of delivering applications of value that address the business needs in terms of capability as well as budget and schedule needs.

While agile is becoming main stream on small and mid-sized projects, challenges do exist elsewhere such as how to manage this approach on larger projects and in distributed development. Another challenge for many is how to apply a requirements lifecycle to agile projects. Many agile principles such as “just enough and no more”, to “begin development before all requirements are complete”, to “test first”, can be counter-intuitive. Also, what about non-functional requirements? What about testing independence? How can we cost something if we don’t know what the requirements are?

This article attempts to describe some ways to handle these challenges. It is based on an example of real, ongoing, and very successful product development that uses agile with a globally distributed team. It describes one set of techniques that is known to work.

Process Overview

There are many “flavors” of agile, but at a high level they all essentially adhere to the following basic principles:

PRINCIPLE	DESCRIPTION
Iterative	Both Requirements and Software are developed in small iterations
Evolutionary	Incremental evolution of requirements and software Just Enough “requirements details”
Time-Boxed	Fixed duration for requirements and software build Iterations
Customer Driven	We actively engage our customers in feature prioritization We embrace change to requirements/software as we build them
Adaptive Planning	We expect planning to be wrong

Requirements details as well as macro level scope are expected to change as we progress through our release.

For the purposes of this article, our example uses a Scrum-based Agile process1. In this approach the iterations (sprints) are two weeks in duration. A sprint is a complete development cycle where the goal is to have built some demonstrable portion of the end application. It should be noted that while the initial sprints do involve building a portion of the application, often this is infrastructure-level software that’s needed to support features to be developed in later sprints. This means there may not be much for stakeholders to “see”.

Each organization needs to determine the sprint duration that’s optimal for them. It needs to be long enough to actually build something, but not long enough for people to become defocused and go off track (thereby wasting time and effort). We found two weeks to be optimal for our environment.

Key during the first part of the process is to determine and agree on project scope, also known as the “release backlog”. Determining the release backlog itself could be a series of sprints where the product owner and other stakeholders iterate through determining relative priority or value of features along with high level costing of these features to arrive at a release backlog.

At the other end of the project, development of new code doesn’t extend to the last day of the last sprint. We typically reserve the last few sprints, depending on the magnitude of the release, for stabilization. In other words, in the last few sprints only bug fixing is done, and no net new features are developed. This tends to go against the agile purists approach to software development as each sprint should, in theory, develop production ready code. However, to truly achieve that requires significant testing and build automation that most organizations don’t have in place. This is always a good goal to strive towards, but don’t expect to achieve this right away.

Requirements Definition in this Process

There are several ways you could perform requirements definition in an agile process, but again our goal is to introduce an example that’s been tried and is known to work. This example begins with the assumption that you already have a good sense of the “business need”, either inherently in the case of a small and cohesive group, or by having modeled the business processes and communicating in a way that all understand. So we begin at the level of defining requirements for the application.

Requirements at the Beginning

Begin with a high-level list of features. Each feature is prioritized by Product Management or Business Analysts (depending on your organization). These features are typically then decomposed to further elaborate and provide detail and are organized by folder groupings and by type. If needed to better communicate you should create low-fidelity mockups or sketches of user interfaces (or portions) and even high-level Use Cases or abstract scenarios to express user goals. We sometimes do these and sometimes not, depending on the nature of what’s being expressed plus considering the audience we’re communicating with. For example, if we’re communicating a fairly simple concept (how to select a flight) and our audience is familiar with the problem space (they’ve built flight reservation applications before) then clear textual statements may be “just enough” to meet our goals at this stage. These goals are to establish rough estimates (variance of 50-100%) and based on these and the priorities, to agree on the initial scope of the release (what features are in and which are out).

Once reviewed, this list of features becomes the release backlog. The features are then assigned to the first several sprints based on priority and development considerations.

Click image for larger view
Example High Level Features with Properties

Requirements During the Sprint

With respect to the requirements, the principle of “just enough” is paramount. If the need has been expressed to a degree adequate enough to communicate and have it built as intended, then you’re done. Going further provides no additional value. This means you’ll have a varying level of detail for the requirements across the breadth of the product. For some parts of the product a high-medium level of detail may be “just enough”, while for other more complex areas a very fine level of detail may be needed.

In each sprint there are tasks of every discipline taking place. Requirements, design, coding, integration, and testing tasks are all being performed concurrently for different aspects of the system. The requirements being defined in one sprint will drive design and coding in a subsequent sprint. The net effect is that all these disciplines are active in every sprint of the lifecycle, but the relative emphasis changes depending on what stage you’re at in the project. For example, requirements tasks are being performed in all sprints, but they are emphasized more in the earlier sprints.

In each sprint, the high level features are elaborated into greater levels of detail. This more detailed expression of the requirements usually begins with usage scenarios/stories and/or visuals and it’s expressed in the form of a model. The models can emphasize user interface, use cases, scenarios, business rules, and combinations of these, depending upon the nature of what is being expressed. Sometimes these are created collaboratively but more often in our experience, one person creates an initial version and then holds a review with others for feedback. In our case it is typically the product managers and/or business analysts who create these models and usually between one to three reviews are held with the developers, testers and other stake holders. The review serves multiple purposes including:

To facilitate knowledge transfer to all stakeholders including architects, UE designers, developers, testers, and executive sponsors on what is needed
To allow the architects, UE Designers and developers to assess feasibility
To determine if there is sufficient detail in the requirements to allow development to proceed

With appropriate technology, tests are automatically generated from the requirements producing tests that are 100% consistent with the requirements and enable the immediate testing of code developed during sprints.

Continuous and Adaptive Planning

With this approach planning is continuous and adaptive throughout the lifecycle allowing resources to be redirected depending on new discoveries that come to light during each sprint. This ability to course correct in mid-flight is what gives projects their “agility”. At the end of each sprint we take stock of what was achieved during the sprint and record progress actuals. The work of the next sprint is adjusted as necessary based on this but also based on testing results, feedback from reviews of that sprint’s build, any new risks or issues that surfaced or others that were retired, and also any external changes in business conditions. Estimates and priorities are adjusted accordingly and any changes to release scope and sprint plans are made. In general we try not to make major mid-flight corrections during a sprint, which is one of the reasons why we like two week sprints. If sprints were, say, four weeks then we would lose agility. Also a two week sprint is easier and more accurate to estimate than a four week one.

Click image for larger view
Example Story with Tasks, and Estimates

With respect to the requirements, for those features assigned to the sprint along with any high-level requirements models, development creates high-level goals for the particular feature and estimates them. The goals express what aspects of the feature they will attempt to build during that sprint, recognizing that one sprint is often not enough time to implement an entire feature. The feature and its high-level goals become the content of the “story”. Once the story is defined the developer then details and estimates the tasks to be done for that story over the next two weeks (sprint) and proceeds with development, tracking daily progress against these tasks in an agile project management tool, and covering issues in the daily scrum.

What about the Non-functional Requirements?

The various agile approaches have evolved several techniques to express system functionality. These are things like user stories, use cases, or usage scenarios, that represent “observable system behaviors and artifacts that deliver value to users” like screens, reports, rules, etc. These functional requirements express “what” the system is to do. Examples of this could be things like “generate a stock-level report”, “make a car reservation”, “register for a webinar”, or “withdraw cash”.

Associated with the functionality of a system are its “qualities”. These express “how well” the system is supposed to do what it does – how fast, how reliably, how usable, and so on. Sometimes these non-functional requirements are associated with certain functional requirements and other times they apply to whole portions of the system or the entire system. So how do these very important requirements get accounted for in our agile process?

They are expressed at the high-level in the form of textual statements. For example: “Any booking transaction shall be able to be completed by a user (as defined in section a) in less than three minutes, 95% of the time”.

As functional requirements are decomposed and derived any associated non-functional requirements should similarly be decomposed, derived, and associated to lower levels. For example the above performance requirement is associated with all the “booking transaction” functional requirements (book a car, book a flight, book a hotel). If the functional requirements are decomposed into the lower level requirements “select a car”, “choose rental options”, and “check-out”, then the non-functional requirement may similarly be decomposed into requirements for selecting a car in less than 30 seconds, choosing options in less than one minute, and checking out in less than 1.5 minutes.

During review sessions the functional requirements take center stage. However, during these reviews any non-functional requirements that are relevant need to be presented and reviewed as well. Traceability is usually relied on to identify them. Any non-functional requirements relevant to the functional requirements of the story need to be expressed as part of the story, so the developer can take these into account during development.

QA needs to create tests to validate all requirements, including the non-functional requirements. Sometimes before a feature has been completely implemented, non-functional requirements can be partially tested or tested for trending, but usually cannot be completely tested until the feature is completely implemented (which can take several sprints).

What about Testing?

The high degree of concurrency in agile processes means that testing is performed in every sprint of the lifecycle. This can be a considerable change from traditional approaches and offers several benefits. First, it tends to foster a much more collaborative environment as the testers are involved early. It also, of course, means that items which wouldn’t have been caught until later in the lifecycle are caught early when they can be fixed much more cheaply.

In agile, Product Owners play a very big role in the testing process and they do so throughout the development lifecycle. Whereas many traditional approaches often rely on requirements specifications as “proxies” of the product owners, agile places much more reliance directly on the product owner effectively bypassing many issues that can arise from imperfect specifications. In addition to the product owners, developers also test. Test-driven development is a prominent technique used by developers in agile approaches where tests are written up-front and serve to guide the application coding as well as performing automated testing, which helps with code stability. To augment test driven development, which is primarily focused at the code level testing done by developers, new technologies that can auto-generate functional tests from functional requirements enable a QA team to conduct functional testing based on test cases that are not “out of sync” with the requirements specification. This enables the QA team to conduct testing on a continuous basis, since executable code and test cases are available throughout the lifecycle. In our example, all three are employed – product owner, development staff, and independent QA – on a continuous basis.

The requirements that we develop in our example are a decomposition of high-level text statements augmented by more detailed requirements models that give a rich expression of what is to be built. Requirements reviews are based on simulations of these models and they are incredibly valuable for a number of reasons. First, just as agile provides huge benefit by producing working software each sprint that stakeholders can see and interact with, simulation lets stakeholders see and interact with ‘virtual’ working software even more frequently. Second, people often create prototypes today trying to do much the same thing. The difference with prototypes, however, is that simulation engines built for requirements definition are based on use cases or scenarios and, therefore, guide the stakeholders in how one will actually use the future application, providing structure and purpose to the requirements review sessions. Prototypes, including simple interactive user interface mock-ups, on the other hand, are simply partial systems that ‘exist’ and provide no guidance as to how they are intended to be used. Stakeholders have to try to discover this on their own and never know if they’re correct or if something has been missed. It is important to note that the principle of “just enough” still applies when producing these models. We rely on the requirements review sessions held with designers/developers to determine when it is “enough.” This approach produces very high quality requirements and it is from these requirements that the tests are automatically generated. In fact, such thorough testing at such a rapid pace without automatic test generation is likely not possible.

Although we strive to have shipable code at the end of each sprint, this goal is not always achieved, and we may need to use the last sprint or two to stabilize the code. Since testing has already been taking place continuously before these final sprints, the application is already of considerably high quality when entering the stabilization phase, meaning risk is manageable and rarely is ship date missed.

What about Estimating?

Remember in agile it is typically ‘time’ that is fixed in the triad of time, features, and quality. In our approach also remember that, with continuous testing and the reserving of the final sprints for stabilization, quality tends to be fairly well known as well. This leaves the features as variable so what we’re actually estimating is the feature set that will be shipped.

As always, the accuracy of estimates is a function of several factors but I’m going to focus on just three

The quality of the information you have to base estimates on,
The inherent risk in what you’re estimating, and
The availability of representative historical examples that you can draw from.

In our approach, estimates are made throughout the development cycle, beginning in the initial scoping sprints. As mentioned earlier, once the list of candidate features is known and expressed at a high (scoping) level, they are estimated. Naturally at this point the estimates are going to be at their most “inaccurate” for the project lifecycle, since the requirements have not been decomposed to a detailed level (quality of information). This mean there is significant risk remaining in the work to be done. Similar projects done in the past may help mitigate some of this risk and help increase the accuracy of the estimates (e.g. we’ve done ten projects just like this and they were fairly consistent in their results).

The initial estimates are key inputs to the scoping and sprint-planning processes. As the project proceeds, with each sprint risks are exposed and dealt with, requirements are decomposed to finer levels of detail, and estimates naturally become more accurate. As you might guess, estimation is done toward the end of each sprint and is used in the planning of future sprints.

What about Distributed Teams?

Today distributed development is the norm. For reasons of efficiency, cost reduction, skills augmentation, or capacity relief, distributed development and outsourcing is a fact of life. There’s no free lunch however – there are costs associated with this approach, and much of these costs are borne in the requirements lifecycle. Chief among these is “communication”. There are practices and technologies that can mitigate this issue, so that the promised benefits of distributed development can be realized. The approach in this we’ve looked at here, for example, uses the following and has been very successful:

Concerted effort for more frequent communication (daily scrums, and other scheduled daily calls)
Liberal use of requirements simulation via web-meeting technology
Direct access to shared requirements models via a central server
Automated generation of tests and reviewing these in concert with the requirements to prove another perspective of what the product needs to provide.

Conclusion

“Have you heard that England is changing their traffic system to drive on the right-hand side of the road? But to ease the transition they’ve decided to phase it in – they’ll start with trucks”.

A common mistake of development organizations making the shift from waterfall to agile is that their organization mandates they still produce their big, heavy set of documents and have them reviewed at the same milestones, clinging to these familiar assets like security blankets. It doesn’t work. As scary as it might seem all significant aspects of the approach, like documentation, need to change in unison if it’s to be successful, and requirements are one of those significant aspects.

However if you still want that security blanket and you want to have some benefit of agile, at least generate your requirements specification in an agile manner (iterative, evolutionary, time boxed, customer driven, adaptive planning) that includes simulations integrated and driven by use cases traced to feature. This is one way to reap some agile benefits without making the leap all at once.

Risk is the ‘enemy’ on software projects. High risk profiles on projects drive uncertainty, render estimates inaccurate, and can upset the best of plans. One of the great things about agile is that its highly iterative nature continually ‘turns over the rocks’ to expose risk early and often so it can be dealt with.

On the other hand, one of the great challenges for larger and distributed teams is keeping everyone aligned as course-corrections happen sprint by sprint. A big part of this is the time and effort it takes to produce and update assets and the delays caused by imperfect and strained communication. The good news is that tools and technologies now exist to produce many of the assets automatically, and to also dramatically improve communication effectiveness, allowing agile to scale.

With the right approach, techniques and technology, distributed agile can be done. We’ve done it. So can you.

References

1 The Scrum Alliance http://www.scrumalliance.org/

2 Approaches to Defining Requirements within Agile Teams
Martin Crisp, Retrieved 21 Feb 2009 from Search Software Quality, http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310960,00.html

3 Beyond Functional Requirements on Agile Projects
Scott Ambler, Retrieved 22 Feb 2009 from Dr.Dobb’s Portal, www.ddj.com/architect/196603549

4 Agile Requirements Modeling
Scott Ambler, Retrieved 22 Feb 2009 from Agile Modeling, http://www.agilemodeling.com/essays/agileRequirements.htm

5 10 Key Principles of Agile Software Development
Retrieved 22 Feb 2009 from All About Agile, http://www.agile-software-development.com/2007/02/10-things-you-need-to-know-about-agile.html

6 Agile Requirements Methods
Dean Leffingwell, July 2002, The Rational Edge

7 Requirements Honesty
Francisco A.C. Pinheiro, Universidade de Brasilia

8 Requirements Documents that Win the Race
Kirstin Kohler & Barbara Paech, Fraunhofer IESE, Germany

9 Engineering of Unstable Requirements using Agile Methods
James E. Tomayko, Carnegie Mellon University

10 Complementing XP with Requirements Negotiation
Paul Grunbacher & Christian Hofer, Johannes Kepler University, Austria

11 Just in Time Requirements Analysis – The Engine that Drives the Planning Game
Michael Lee, Kuvera Enterprise Solutions Inc., Boulder, CO. 03/09