Incremental vs. Conventional Requirements Gathering

Regardless of which development method is used for a project, the first step is always to gather the requirements. Just as no builder would try to construct a house without knowing the square footage, number of bedrooms and budget, you must first determine the size, scope and purpose of the finished product.

The requirements gathering phase is where customers and developers interact to determine this information. However, requirements gathering is much different for projects developed under the traditional waterfall method and those developed using agile methodology.

Requirements Gathering for Conventional Waterfall Method

The waterfall method of development requires that all development progress in a forward-moving manner. Once a stage has been completed, going back to make changes can be costly, both financially and in terms of delayed deployment. Therefore, all requirements for the entire project must be clearly defined before the first line of code is written.

With so much information to be gathered and analyzed, this initial phase can take weeks, if not months. Easy wins — the low-hanging fruit that lends itself to a quick fix — must be ignored until the entire project has been mapped out. Such an approach carries the following drawbacks:

• Slow initial implementation that delays any return on investment
• Possibility that business needs can change before development begins
• Expensive to revamp requirements if they change
• Chance that an important requirement may be missed or under-emphasized
• Risk that final product will not be satisfactory due to omitted or misunderstood requirements

Because the client may not see the finished product until a beta version is ready to be tested, the waterfall method carries the risk that many months could be wasted on developing a product that does not do what the client needs. The delayed deployment could result in missed opportunities to expand the business or lost sales due to dissatisfaction with the current system. Although there is no universal law on the issue of who bears the cost of a failed development project, the general rule is that if the client failed to provide accurate, clear and complete requirements, the client must bear the costs of the doomed project.

Advantages of Agile Methodology

The agile development method breaks the project into independent blocks, each of which can be completed in a relatively short time — usually less than three weeks. In most cases, all or almost all of the features can be developed, approved, tested and implemented separately.

You can choose to implement features independently to score quick wins and begin realizing a return on your investment. If a requirement has been overlooked or miscommunicated, the oversight can be quickly remedied with minimal delay and cost. Similarly, if business needs change, new features can be added or existing features modified with minimal impact to the project.

Requirements Gathering for Agile Projects

Requirements gathering for agile projects is quite unlike requirements gathering for waterfall projects. Instead of trying to detail the requirements for the entire project, the process begins by having the client write user stories that describe the type of user, what the user needs to do and what the user hopes to accomplish from his actions. The following examples illustrate the concept of user stories:

• As a field sales representative, I need the ability to access inventory records so that I can advise customer on delivery time.
• As a field services manager, I need the ability to push work orders to techs so that I can optimize schedules and routes.
• As the manager of production planning and scheduling, I need to access order backlogs so that I know what raw materials need to be ordered.
• As the system administrator, I need the ability to grant new employees with the correct access level so that they can access the data they need while restricting sensitive information.

These stories answer three questions:

• What is the user type? (Who is the user?)
• What action does this user need to perform?
• Why does the user need to perform this action?

Once the user stories have been compiled, the developer can begin to build the entire project. Each user story is a brick in the completed project. In most cases, many or all of the user stories can be transformed into a feature. Individual features can be prioritized, with the critical features developed and deployed first. Should priorities change, it is not a major issue to rearrange the order of development, and if new features need to be added, they can be included without incurring excessive costs for modifying the project.

It is important to remember that user stories do not involve the “how” of development. They merely describe what is needed. If a development team knows what a feature needs to do, it can easily determine what tools are needed to accomplish the task.

Gathering User Stories

Some clients may deliver a list of user stories to a developer at the outset of the project. More often, the developer must guide clients through the process. An interview with the client and a large cross-section of the company’s employees can prove beneficial. Developers should encourage users to “brainstorm” freely without considering the technical aspects of the request.

When interviewing users, it is best to ask open-ended questions. Here are some examples of good questions to ask:

• How do you need to search for a customer’s address?
• With which departments do you need to interact?
• What features do you feel are lacking in your current system?

Conversely, here are examples of bad questions to ask:

• Do you need the ability to search for a customer’s address by city? (The user probably does need this feature, but the question could prevent the user from stating that he would prefer the ability to search by customer number.)
• Do you need to interact with the sales department? (The user may also need to interact with production, payroll, purchasing, logistics and customer service. However, unless you ask about each department separately, the user may be reluctant to specify all the different departments.)
• Are you happy with the reports you can generate with your current system? (An affirmative answer does not necessarily imply that the user feels there are a sufficient number of reports available — just that he has no complaints with the ones he can generate. This also does not imply that he does not need additional reports, and it does not address whether he is satisfied with the search features or any other aspect of the system.)

Additional Requirements

Projects have requirements beyond the user needs. These requirements may include:

• Processing speed or performance
• Scalability
• Security
• Mobility
• Maintainability
• Availability

Additional requirements may apply to specific projects.

These type of requirements are often called non-functional requirements or system constraints. They must be identified so that developers can keep them in mind when addressing the functional requirements.

In Conclusion

The agile and conventional waterfall methods of development are quite different, so it is only logical that the requirements gathering phases are also quite different. The basics are:

• When using the agile method, first define features, not the entire project.
• Collect user stories to determine what each feature needs to do.
• Decide the best way to implement each feature.
• Prioritize features.
• Tie features together to build the complete project.

There are numerous advantages to using the agile method when developing large projects. However, some benefits can disappear without understanding that requirements gathering for agile projects is not the same as requirements gathering for conventional projects. Although it may take a little time to adapt to the differences, the time spent can pay off handsomely.