I. The Business Case for Requirements Engineering
Projects have high failure rates, and evidence points to problems with defining requirements as one primary cause. This section presents an overview of the challenges inherent in projects in general, and specific problems typically encountered with project requirements.

A. The goal of a project
B. Facts and figures about project success and failure
C. Types of requirements errors and their frequency
D. The high cost of requirements errors

II. Foundations of Requirements Development
Developing requirements is key to project success. In this section, we’ll cover some basic definitions, review a requirements development framework and process, and introduce an example system we’ll use for our practice sessions.

A. The Business Analysis Body of Knowledge
B. Definitions of terms
C. Types of requirements
D. Characteristics of well-written requirements
E. The requirements development roadmap
F. Requirements and the development life cycle
G. Enterprise analysis

Practice Session
Gain an in-depth look at a hypothetical but realistic business and one of its key systems that you’ll be eliciting and managing requirements for during the class.

III. Project Initiation
Projects arise in part to solve business problems, and understanding the underlying problem or problems is therefore key to being able to identify the correct requirements. During this section, you will refresh your knowledge of and practice defining and documenting project scope and key business requirements.

A. Defining goals and objectives
B. Identifying stakeholders and user classes
C. Identifying constraints and benefits
D. Specifying exclusions
E. Modeling the system scope
F. Documenting requirements in the Initiate phase

Practice Session
Guided by your instructor, you will work with a team to define the goals and objectives in an example project. You’ll have a chance to practice identifying stakeholders and constraints and discovering important aspects of the project scope. You’ll participate in documenting the project scope using a variety of business models.

IV. Eliciting Functional and Non-functional Requirements
As we come to understand the business problem at the heart of a project, we need to learn to capture our business customers’ functional and non-functional requirements. This section explores several powerful and effective analysis techniques for requirements elicitation and development.

A. Problems with requirements elicitation
B. Techniques for eliciting customer requirements
C. Analyzing and reviewing documents and artifacts
D. Modeling processes, analyzing gaps and generating questions
E. Interviewing the stakeholders
F. Identifying data requirements
G. Establishing requirements traceability
H. Capturing the requirements

Practice Session
In your team, you will analyze business artifacts and documents to discover the customers’ functional requirements for the solution. You’ll practice identifying what functionality customers want to keep, remove, add and/or change in moving from their current system to the solution. You’ll practice generating questions for key stakeholders and interviewing those stakeholders. Finally, you’ll learn to use a variety of tools to discover and document stakeholders’ data requirements.

V. Use Cases: A First Look
A”use case” is a sequence of events performed by an actor (person, automated system, or both) in a business environment to get their job done. Use cases carry significant requirements for a system from the perspective of a business user. Use cases are a critical tool in the analysis process, helping us understand what the system needs to do. Later in the development life cycle, use cases aid in design and implementation, testing, and user documentation for the new system. This section introduces the concept of use cases and gives you an opportunity to explore this analysis technique.

A. The benefits of use cases
B. Use case basics
C. Finding use cases
D. Building a use case model
E. Deriving requirements from a use case
F. Tracing requirements from use cases

Practice Session
Your team will create a use case model for one process of our example system. You’ll learn how to identify and extract important functional requirements from the use case, how to elicit additional requirements, and how to maintain traceability among the requirements. You’ll discover how the use case becomes the basis for future development tasks.

VI. Reviewing and Refining Requirements
Well-defined requirements are critical to producing a system that meets the needs of the project stakeholders. Finding the requirements is only the first challenge. Once discovered, requirements must be reviewed, analyzed, validated and possibly rewritten. All requirements must then be confirmed with project stakeholders before the final specification is published.

A. Writing requirements
B. Reducing ambiguity
C. Validating requirements through reviews and inspections
D. Analyzing requirements for validity, consistency and effectiveness
E. Refining requirements
 

Practice Session
Your team will evaluate the requirements that have been found and written for the example project to identify any that don’t meet the quality characteristics we’ve defined. We’ll practice rewriting any unclear or ambiguous requirements.
 

VII. Creating a Requirements Specification
“The job’s not finished ‘til the paperwork’s done.” The final deliverable for many projects is a Requirements Specification of some kind. Writing a clear, concise and informative specification is a critical step in providing the implementation team with the information they need to design and implement a solution that is right for the stakeholders of the project. This section focuses on the creation and communication of the final requirements specification.

A. Organizing and classifying requirements
B. Documenting requirements: the Software Requirements Specification (SRS)
C. Documenting traceability

Practice Session
Your team will consider a model template for documenting the final requirements specification for our case project. You will have an opportunity to write sections of the specification in the course.

Section I: Agile Overview
More than simply a methodology or approach to software development, Agile embraces a set of principles that drive more effective software development. Agile focuses on the customer, embraces the ever changing nature of business environments and encourages human interaction in delivering outstanding software. In this introduction, we'll discuss the following:

• Agile Manifesto
• Agile Principles
• Agile Methodologies
• Agile Benefits 

Section II. Project Initiation
Among the key contributing factors leading to project failure is poor communication between the customer and developer groups. It is critical, therefore, that each successful project start out right. In this section we'll cover the following topics:

• Project Charter
• Project Roles
• Project Planning
• Communication 

Class Exercise
Working in small teams, you will establish a project charter including goals and objectives for a sample project. You will participate in defining key roles for project team members and set clear expectations for project communication.

Section III: Focus on the Customer
It is critical that the customer be the focus of a product throughout the development lifecycle. Every requirement should bring some value to the customer. Therefore, prior to defining requirements, it is important to define the customer. This will include the following topics:

• Customer Involvement
• Customer Roles
• Creating and Using Personas
• Constraints 

Class Exercise
Within your teams you will brainstorm some customer roles for your example project. From the brainstorming, you will consolidate the larger list of roles into key roles that will be the focus of your sample project. For each of the key roles, each team will create personas and share them with the class.

Section IV: User Stories
User stories are a way to capture requirements from a customer point of view. Stories do not capture all of the detailed requirements, but require enough information to estimate and plan. A proven tool used in Agile teams to capture initial requirements, in this section we will explore the following topics:

• User Stories
• Goals and Objectives
• Acceptance Criteria and Acceptance Tests
• Non-user Stories

Class Exercise
Led by the instructor, the class will come up with some user stories for a sample project. We will discuss how to determine as a team what is appropriate for your user stories to be effective.

Section V: Product Backlog
The Product Backlog is the complete list of desired elements, or requirements, for the product. It is NOT a Requirements Specification, but a high level identification of what the software may satisfy. In this section we will discuss effective means of creating, prioritizing and maintaining the Product Backlog. We will peruse the following topics:

• Who owns the Product Backlog?
• Functional and Non-functional Requirements
• Story-Writing Workshop
• Prioritizing the Product Backlog
• Maintaining the Product Backlog
• Techniques for further elaboration

Class Exercise
In small teams identified previously, you will engage in a story-writing workshop as a means of building a product backlog for your sample project. Subsequently, you will participate in prioritizing your product backlog and present the highest priority stories to the class.

Section VI: Estimating and Planning
Among the greatest challenges in developing software and delivering against stakeholder expectations is estimating accurately and subsequently planning how those expectations can be met. Agile cannot make that challenge disappear, but offers some very helpful tools that enable teams to set and meet the appropriate expectations.

• Relative vs. Actual Estimating
• Using Story Points
• Planning Poker (Grenning 2002)
• Five Levels of Planning in Agile
• Estimating Team Velocity

Class Exercise
Using the estimating techniques taught using story points, you'll enjoy a few rounds of Planning Poker with your team to establish estimates for your highest priority stories. This fun and highly effective method of relative estimating is certain to be a valuable tool for you to incorporate into your own estimating process.

Section VII: Release Plan
The release plan identifies a goal for the stories that will be included for a release of the software. Through the prior processes, the team will have prioritized the stories and estimated the team velocity. These key elements will come together to give the team a level of confidence that they can deliver the necessary requirements for a product release in what is normally a fixed timeframe. We'll examine the following topics:

• Iteration Estimates
• Prioritization Revisited
• Ownership and Participation
• Communication 

Class Exercise
Each team will establish a release plan for their sample project incorporating priority, estimates and velocity as appropriate. We'll discuss how real experiences of fixed time and requirement projects that work well with an Agile release plan.

Section VIII: Use Cases
At the appropriate time, prior to entering into the development of a story, requirements will need to be discussed in more detail. Use cases are a proven method for documenting the appropriate detail from a user interaction point of view. In this section, the instructor will introduce use cases and discuss some of the foundational elements that support the development process.

• Use Case Advantages
• Use Case elements
• Success Path
• Alternate Paths
• Exceptions

Class Exercise
Teams will discuss and document use cases, including alternate paths and exceptions, for some of their high priority stories. As a class we'll discuss the relationship between use cases and stories, and how they complement each other.

Section IX: Iteration Plan and Execution
An iteration is a fixed amount of time in which stories/requirements will be developed, tested and ready for release. Because the requirements communication process takes you into each iteration throughout the product release, we'll explore the iteration planning and execution process. During this section we will discuss the following topics:

• Iteration Planning
• Defining "Done"
• Test-Driven, Test Often
• Demonstrate Working Software (Delivered Requirements)
• Inspect and Adapt applied to Requirements
• Finding your rhythm 

Section X: Retrospective on Communicating Requirements
Using Agile Methods – Retrospectives are a key practice in Agile. We will take an opportunity to review our learning collectively and how we can improve. Each participant will identify one or two things that they will adapt in their working environment based on their learning. The instructor will also identify any elements of the course that should be adapted for a better learning experience, thus benefiting future course participants.

In-Class Group Exercises:

In-class exercises help you identify and examine firsthand problems that you may experience. With our demonstrations and case studies, you will discuss ways you can handle problems up front, and how you can make improvements, throughout the phases of requirements development.

• Establish a project charter, define roles for the project team and determine appropriate communication
• Define customer roles and personas 
• Document requirements with user stories 
• Create and maintain a product backlog 
• Determine customer value and priority for each user story 
• Participate in engaging and innovative estimating techniques 
• Communicate a release plan for a product 
• Document requirement details with use cases 
• Plan and execute an iteration cycle 
• Learn how to continuously improve requirements collaboration