The majority of corporate executives are not interested in knowing the finer detail of an information technology department's Software Development Life-Cycle (SDLC). They glaze over when they hear terms like Scrum andKanban, and acronyms like XP, TDD and RUP. However executives do want new features and business processes as soon as they ask for them. If you cannot deliver the enhanced capability in a timeframe matching their "reasonable" expectation then whatever process you use may be viewed as the wrong way to do it. In order to manage expectations while delivering capabilities and IT operations, it is important to understand the benefits of the SDLC your organization adopted in the first place and why it is still the most applicable process today. At the forefront of all SDLCs is knowing WHAT to build, and requirements are front and center in understanding it.

Let's take a look at the differences between Waterfall and Agile requirements, how they are managed, and the philosophy behind documenting requirements in these two different ways.

A Brief Overview of An Agile Environment

Surprise! Agile teams actually do document requirements, and you better know what you are building in a sprint before you start it. Because it's going to go fast, and if you haven't thought through scenarios for the features ahead of time, you are in for a pretty hard ride as an analyst, project manager, product owner or Scrum master. If you are implementing a project using Scrum in the enterprise, you still have at least a QA tester or two. Hopefully you have one business analyst and three or four developers as well (I guess someone actually has to create the stuff). If you want testers to write good acceptance tests, then you better have good direction for them as a team. Usually direction comes from documentation, so you may need some at this point. The code won't write itself after all. So what's the difference between this and Waterfall again?! In Agile teams, the documentation should capture the results of work already in progress. This occurs in discussions with the technical team; some teams will capture the documentation while developers implement the solution.

A mature agile organization will have long term roadmaps established at the business tier, and features will be organized around potentially shippable increments (PSIs). Requirements have to exist at both the business tier and the team tier that delivers the PSIs. The requirements in this SCRUM process and the traditional software requirements specifications document (SRS) reveal differences in how the team consumes them.

While you may not have a requirement that says "The system shall have a 3 point border around the heading", you will have a picture that specifies that requirement through an appropriate document type. Successful agile teams have usually worked together for some time, and they know how to extract requirements out of documents in this fashion. They don't need the 500 commandments from an SRS. Those who eventually will support the system will have acceptance tests and user manuals at their disposal. So where do those manuals come from?

Generally after all that great team collaboration and elicitation from the various stakeholders, someone has to write something that future support teams and development teams will consume to enhance and manage the new application. Usually the code is complete at this point, and while the system is ready for production, the documentation for these future consumers is developed. In the meantime, immediate supporters of the system may have resources like Automated Functional Acceptance Tests to determine the stability of the system in production.

Requirements from 0 to Release

When the folks at the business tier have their feature sets prioritized and ready to communicate and assign to an Agile team's backlog, the detailed requirements start showing themselves. These take the form of user stories discovered by decomposing Epics grouped by the initial features requested by the business. Features. Stories. Epics. Most folks googling "Agile" have seen these three terms. And conceptually, it really is this simple, but the model identifies complications:

Agile Requirements Model

Much more can be added to this model by throwing in constraints like Non-functional requirements that must be satisfied at all levels. A deeper dive into the User Story layer often reveals even more complexity, but by showing decomposition and completion at the story layer, this model helps management understand what is being developed, and what has yet to happen. The User Stories act as containers for documentation. For example, you will most likely have deliverable such as UX diagrams, Visual Designs, Business rules, Acceptance Criteria, Acceptance Tests and even Use Cases (dare I mention them in an agile blog) inside the User Story container relating to the implementation. Managing all of this can be even more daunting then large SRS documents on SharePoint, but luckily most organizations have applications like Rally, VersionOne or some other repository to help you with all of this. The big difference between this model and Waterfall is that some of this content describing the requirements is discovered while working on the user story or breaking down the Epic. That means that coding does start without going through every single exception scenario that your grandmother's cat may experience while using the application before coding.

This does not seem simple anymore.

Well, it doesn't seem simple on the surface here, but although the model may get complicated in the enterprise, it simplifies building applications by enabling more robust requirements discovery tools by building code earlier. And as I said at the beginning, it's not for every organization, so you still have to know what teams work well consuming agile requirements rather than consuming detailed SRS documents. In the end, you have acceptance criteria/acceptance tests that can feed into support documentation for those that maintain the system and still have consensus in the organization about what you built, and what risk there is letting it loose in production.

"Agile Requirements" is not an oxymoron; agile teams care about building the right thing as much as anyone else, and those that take the time to understand the implications of the model described here can have success building solutions at any level of complexity.