Agile Business Analysis: Getting / Writing Lean Requirements

The Agile Manifesto and Lean Manufacturing Principles have changed the IT landscape. This lecture provides a basic understanding of what these are and why they are important.

Over the past 70 odd years, every study of IT project failures has identified missing and misunderstood requirements as the major contributor. This section explains how Agile and Lean philosophies attempt to solve this seemingly intractable problem.

Eliciting requirements includes the simple process of asking questions but that is just the tip of the iceberg.

The simple act of creating and maintaining an open Question File from the beginning of the project through to the end keeps you abreast of your analysis progress and provides a detailed project history. This is the ideal format for a lessons-learned evaluation.

There are 5 fundamental approaches for eliciting requirements and each has its own pros and cons. In addition, each requires some level of planning, performing, and publishing.

Stakeholder identification is one of the more critical early project activities. Missing critical stakeholders early in the project always leads to missed delivery dates or failed projects.

Although you have been communicating with other people since before you learned how to talk, finding the right tone and content of a requirements elicitation conversation can still be challenging.

The core idea of non-verbal communication sound trivial, but experience teaches us that words not spoken often contribute more to accurate understanding than everything the person says.

A comedian once quipped, "Earth would be such a lovely planet if it weren't for all the people." Whether you agree with that comment or not, it obviously is not a great attitude for anyone trying to elicit requirements. We all have issues with certain behaviors of other people, in particular when we are trying to achieve a specific outcome from our interaction. The good news is that there are ways of dealing with every behavior, if you only have time to think about them and plan ahead.

Listening is an art, no doubt. When you are trying to elicit requirements, you need to apply powerful listening techniques to ensure that you get the right information out of the conversation.

There are seven critical criteria for conducting effective requirements gathering conversations.

Before you can start to discuss solutions, you should make sure that you are looking to solve the right problem. This simple problem analysis approach will start you down the right path.

Once you have a list of potential problems, the challenge becomes how to reduce the list to the essential or "real" problems and separate out solutions or symptoms. 

The simple construct called a "User Story" is one of the best modes for expressing stakeholder requirements.

There is immense power in simplicity. Expressing your requirements in simple, single, complete sentences will dramatically increase the number of people who understand what it really means. A good User Story is not a Victorian novel but a trigger for a conversation.

Unless the agile team knows what value a user story delivers, they have no way of determining its relative importance.

Given that projects are restricted by budgets, you should ensure that every request is relevant, meaning in scope, for your project before you spend time delving into details of the request. Your first question should always be, "How does this request contribute to meeting the goal of the project?"

Recognize how ambiguity and subjectivity in requirement statements, user stories, features, etc. impede achieving a common understanding among all audience members.

Identify four common contributors to ambiguity that cause misunderstandings.

Use desk checking, peer reviews, and peer rephrasing to discover hidden ambiguity and subjectivity

Evaluate who is best suited to critique and revise your requirements, user stories, etc.

In spite of impressions, testing is the most time-consuming activity in the process of delivering IT applications. Unit, Integration/system, and acceptance testing consume about 45% of the total development time. This lecture introduces test-driven development techniques for improving the efficiency of the testing process.

Test data engineering uses equivalence classes, boundary values, and probable error to limit the number of tests required to achieve confidence that the application works as intended.

Decision tables are a reliable analysis tool for ensuring that an application behaves as intended in all possible situations.  A bonus is that the decision table leads directly into test scenarios.

Assuming you are able to perform basic problem analysis to distinguish symptoms from problems, the symptoms provide a treasure test of test scenarios for acceptance testing.

Commonly considered a development or analysis tool, use cases lay the groundwork for testing as well.

This lesson introduces 2 additional, lesser-known methods for identifying test scenarios that other approaches miss.

Identifying the functions that the application must support or that people need to use the application leads inexorably to test scenarios for unit, integration/system, and ultimately acceptance testing.

Once you have identified the functions the application performs, you need to consider what data each function needs and what data it creates to fine-tune your test scenarios.

Non-Functional Requirements (NFR) are often the cause of IT project failure. It is not enough to know the application does what it should do. The question is does it do it well enough, fast enough, often enough? Learn the most common types of NFR that are often neglected.

Asking the right questions early in the process is key to determining which Non-Functional Requirements your project has to meet.

Discover why constraints form a special category of Non-Functional Requirements and are the most challenging to test.