With the advent of Agile and Requirements Visualization, complex software applications are being developed faster than ever before. Business Analysts often find themselves in a chase situation where they must not only rapidly produce quality requirements, but quite often solve the same problem again and again. Solving the same problem more than once can lead to duplicate requirements, which pose a significant problem for project teams in all phases of the Software Development Lifecycle. This article outlines an approach for addressing this issue at the Enterprise level by developing a series of reusable requirement standards in the form of Requirements Design Patterns that can be leveraged by Business Analysts across the Enterprise.
A Design Pattern is defined by Wikipedia as: “… a formal way of documenting a solution to a design problem in a particular field of expertise.” Think of a Requirements Design Pattern as a reusable “Requirements Widget” that has prior approval for use within the company, and that can be quickly applied to new situations.
Requirements Design Patterns typically have the following attributes:
- ID: a unique identifier used when referencing a pattern
- Version: for tracking changes and approvals
- Name: name of the Design Pattern, such as “Login Widget”
- Input: any inputs required for the pattern to function
- Output: the expected output or result of applying the pattern
- Description: a detailed description of the pattern, and any clearly defined inputs or outputs relevant to when the Pattern is applied.
- Requirements Detail: the detailed requirements associated with the pattern.
Example:
ID: 1
Version: 1.0
Name: Login Widget
Input: Username, Password
Output: The user is logged in and taken to their homepage.
Description: The Login Widget is the form present at the top right corner of our corporate websites that allows a user to login to access their homepage.
Requirements Detail: [Detail for the requirements related to the Login Widget.]
A good practice is to review Requirements Design Patterns like any traditional requirements documentation, and then once approval is obtained, to version and track it in a central repository, where Business Analysts can easily access it across the Enterprise. If your company leverages Visualization technology, requirements can often be documented in the Visualization itself, so that when the reusable component is applied to a new Model, the requirements are added automatically, resulting in significant time savings.
In the fast moving world of software development, it’s tempting to want to simply focus on only solving the problem at hand, rather than developing a solution that can be applied and leveraged by others to solve problems in the future. Consider it a challenge on your next project to develop some reusable Requirements Design Patterns of your own, and then share and champion them; you would be amazed at the time and cost savings that can result in the future by developing a single reusable solution today.
About the Author
Chris Staufer is a Sr. Visualization Analyst with OneSpring. When he’s not developing innovative ways to document requirements for federal and corporate customers, he enjoys practicing martial arts and spending quality time with his wife. Chris lives in Atlanta.
