Aligning Lifecycle Methodologies - Part 1

In a previous post, I contended that requirements are still an important part of most enterprise environments, even those that might be using Agile lifecycle methodologies. However, I didn't specify exactly how those requirements should be captured — or even what constitutes a requirement. This is an important question when determining how to align multiple lifecycle approaches within one organization (the need for which is much more common than most people realize)

This question encompasses two major lifecycle approaches; Agile and Waterfall methodology. Many organizations feel that User Stories (Agile) are sufficient to build both code and project structures around them. Is it out of the question to consider that Use Cases might be used within an Agile approach?

Before answering that, let’s take a look at User Stories, Use Cases and Requirements in context again:

• A User Story can be thought of as a high level or conceptual scenario, or perhaps just a problem. An example might something like this: A user needs to be able to save a report into multiple file formats for downloading, including both .pdf and .xls. Even though we’ve described two different formats, it still represents the same scenario or problem.
• A Use Case, on the other hand, can be considered a functional requirement. The difference between a functional requirement and technical one is the level of detail the document includes about how specific actions are carried out. For example, a use case would capture the process flow, or steps involved in generating the report and the expected outcomes or alternatives. This helps to build test cases later on. A use case is slightly more structured and detailed and is generally written by someone IT or in combination with the IT group. That way, some of the technical expectations are captured. In other words, the use case describes not just behavior, but how that behavior is achieved.
• A Requirement in this context refers to a technical requirement. This is entirely specific to the elements needed to develop and/or deploy the capabilities described in the previous two documents. It allows us to formalize performance constraints, data elements and other pertinent technical details. This is especially important in environments where EA, service or data governance paradigms are in place. If written properly, requirements can then serve as system documentation.

Mapping across lifecycle approaches begins with requirements (however they're captured)

While many organizations practicing Agile bypass requirements, they may in fact still capture the same information after the fact if they actually document their deployed solutions (after the fact). When you’re considering whether or how to employ user stories and use cases, keep these points in mind:

• They are not the same thing.
• The user story ought to come first.
• The use case ought to be derived from the user story.
• Any requirements managed from this process should be embedded within, or otherwise traceable to, a specific use case and user story.
• User stories could be considered either scenarios, high-level processes or problems.
• Every organization approaches this process somewhat differently. For example, in a less Agile environment, a number of other architecture artifacts could be added to the illustration above:
• At the user story level, many people like to capture a data-flow diagram or a context diagram.
• At the use case level, many folks like to add a UML sequence diagram and conceptual data model.
• At the requirement level, many UML diagrams are often added including activity models, state models, component diagrams or deployment diagrams.
• If a formal EA framework is being applied, those UML or ERD diagrams are often replaced or folded into EA Framework views/artifacts.

Getting back to the original question — should use cases be used with Agile lifecycle management? — my recommendation is yes. Here’s why and how.

Why to Do It

1. It ensures some level of systems engineering is included in the Agile design process.
2. It helps to define the tasks associated with each user story and doesn’t add that much extra effort - it also doesn’t require a use case diagram (which in most cases doesn’t convey that much meaning anyway).
3. It ensures that both IT and business stakeholders capture their expectations in formats tailored to their roles and needs.

How to Do It

• Define your use case template and what it must convey.
• Determine whether user stories require more than one use case. It happens occasionally, although in most situations user stories should be in a 1-1 ratio.
• Ensure that someone from IT helps with, or provides much of the detail, in the use case.
• Ensure that use case development is aligned with both the quality and testing paradigms. This is especially important if no requirements are captured.

The majority of Agile development environments are fairly flexible in regards to storing of related attachments, so the biggest impact to employing use cases along with user stories is in the design and development process. This is the first step towards aligning lifecycle methodologies; we will examine this further in several upcoming posts.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc